TESIS DOCTORAL METODOLOGA, ESTRUCTURA Y DESARROLLO DE INTERFACES INTERMEDIAS PARA LA CONEXIN DE LABORATORIOS REMOTOS Y VIRTUALES A PLATAFORMAS EDUCATIVAS

ELIO SAN CRISTBAL RUIZ

Ingeniero Informtico (Ingeniera del Software) Tesis presentada en la ESCUELA TCNICA SUPERIOR DE INGENIEROS INDUSTRIALES UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA como parte de los requerimientos para la obtencin del Grado de Doctor 2010

II

DEPARTAMENTO DE INGENIERA ELCTRICA, ELECTRNICA Y DE CONTROL

ESCUELA TCNICA SUPERIOR DE INGENIEROS INDUSTRIALES

Titulo de la Tesis: METODOLOGA, ESTRUCTURA Y DESARROLLO DE INTERFACES INTERMEDIAS PARA LA CONEXIN DE LABORATORIOS REMOTOS Y VIRTUALES A PLATAFORMAS EDUCATIVAS

Autor: ELIO SAN CRISTBAL RUIZ

Ingeniero Informtico (Ingeniera del Software)

Director de la Tesis: Dr. MANUEL-ALONSO CASTRO GIL

III

IV

A mis padres, Elio y Antonia, y a mi hermana M Inmaculada que siempre han estado a mi lado. A Manuel Castro y a Alberto Pesquera por su apoyo, sus conocimientos y sus buenos consejos.

VI

RESUMEN Cuando abordamos la labor educativa es de primordial importancia ajustar los medios de los que disponemos al fin que queremos obtener. No slo la base terica, tambin la prctica adecuada a sta o el mtodo de enseanza empleado pueden definir los resultados docentes en un sentido u otro. Es necesario, adems, ajustar la tecnologa y el lenguaje al fin que se persiga para optimizar el proceso y conseguir los resultados que se hayan definido previamente.

En cierto sentido, se trata de optimizar los recursos y adecuarlos a la metodologa de aprendizaje, especialmente importante en la educacin a distancia. La comunicacin, en esta modalidad de aprendizaje, debe cuidarse con esmero por razones obvias. En un proceso comunicativo, la informacin que se emite por un mismo canal, se recibe de un modo ms eficiente que aquella que lo hace por varios a un mismo tiempo.

El proceso de aprendizaje implica, en muchos casos, la unin de dos tipos de conocimiento: un conocimiento terico y una aplicacin prctica de dicho conocimiento. Hasta hace unos aos, ambos conocimientos eran adquiridos de forma presencial: en aulas de aprendizaje y laboratorios fsicos. Actualmente, el desarrollo de las redes comunicaciones y la aparicin de Internet ha impulsado otras metodologas de enseanza, como la enseanza mixta o a distancia. Como consecuencia, las aulas y los laboratorios han pasado a ser virtuales o remotos.

Un estudiante de enseanza a distancia, como cualquier otro estudiante, necesita adquirir conocimiento terico y prctico, con la salvedad de que en muchos casos no puede desplazarse a aulas de aprendizaje donde estar con sus compaeros y recibir clase. Por tanto, es necesario que el estudiante adquiera el conocimiento tericoprctico utilizando otros medios de comunicacin. El medio ms utilizado actualmente es Internet y ms concretamente la Web.

En la actualidad, existen un gran nmero de soluciones educativas para adquirir conocimiento terico, desde pginas web hasta plataformas de aprendizaje. Muchas instituciones y universidades han optado por las plataformas educativas, ya que, adems de organizar y mostrar el contenido terico de una forma secuenciada y estructurada, tambin ofrecen un conjunto de servicios y herramientas orientadas a la colaboracin entre estudiantes y profesores, el seguimiento de estudiantes y la evaluacin de estos. Por ltimo, es importante destacar que la mayora de las

VII

plataformas actuales soportan estndares e-learning para reutilizar objetos educativos o elementos de evaluacin (test, preguntas de rellenado de huecos, etc.). Al mismo tiempo que se han desarrollado plataformas educativas, se ha ido desplegando otra solucin educativa orientada a la adquisicin de habilidades o conocimiento terico. Esta solucin recibe el nombre de laboratorios virtuales o remotos, y como se ha mencionado permiten que un estudiante experimente sobre instrumentos simulados o reales, en cualquier momento y en cualquier lugar. A diferencia de las plataformas educativas, cada vez que se crea un laboratorio es necesario implementar los experimentos sobre este y los servicios y herramientas necesarias para la colaboracin entre estudiantes, el mantenimiento de contenido educativo de las prcticas, etc. No existe reutilizacin, ni estndares e-learning que se apliquen actualmente.

Esta Tesis est motivada por la necesidad de crear una arquitectura o middleware capaz de unir ambas soluciones en una sola y por tanto permitir: Que un estudiante pueda utilizar una nica solucin para adquirir conocimiento terico y prctico. Reutilizar los servicios ofrecidos por las plataformas educativas. De tal forma que los diseadores del laboratorio se puedan simplemente limitar a disear y definir los experimentos ms adecuados a cada laboratorio. Utilizar los estndares e-learning soportados por las plataformas educativas. Y por tanto reutilizar cursos, captulos o elementos de evaluacin realizados por otras instituciones. Reutilizar laboratorios ya existente, dndole la posibilidad a una institucin de no tener que desarrollar el mismo laboratorio, con el gasto que ello supone: econmico, personal, etc. Crear una arquitectura de conexin global de laboratorios y sistemas de gestin de aprendizaje de diferentes universidades e instituciones. Como una red de servicios global.

VIII

SUMMARY In educational projects, it is paramount to adapt our means to the aim we intend to achieve. The theoretical foundation and its associated practice, or the teaching method, may outline the learning outcomes in one way or other. However, it is also necessary to adjust language and technology to the objective with a view to optimize the process and achieve the intended results.

To a certain degree, the aforementioned concerns the optimization of resources and their adjustment to learning methods these being particularly important in distance education, where communication must be specially observed for obvious reasons. In a communicative process, the information that has been transmitted through one single channel is more efficiently received than the information transmitted through several channels at once.

The learning process largely involves the combination of two kinds of knowledge: theoretical knowledge and its application into practice. Until a few years ago, students acquired both kinds by attending classes and physical laboratories. Nowadays, the development of communicative networks and the emergence of the Internet have promoted other teaching methods such as blended and distance learning. Classrooms and labs have become virtual accordingly.

Distance students, like any other type of learners, need to acquire theoretical and practical knowledge only on many occasions they cannot go to learning centers to get their classes and to share them with their classmates. Those students therefore need to acquire theoretical and practical knowledge through other communicative tools, among which the Internet more specifically the World-Wide Web is the commonest.

At present, there are plenty of educational solutions for the acquisition of theoretical knowledge, ranging from web pages to learning platforms. Many institutions and universities have opted for learning platforms. The reason for this is that these platforms organize and display theoretical contents in a sequential and well-assembled way, and also because they offer a set of services and tools whose targets are the collaboration between students and teachers, the follow-up of learners, and the assessment of their work. Lastly, it is worth mentioning that most current platforms

IX

support e-learning standards to reuse educational objects or evaluation elements such as multiple-choice exercises, cloze tests, etc.

Parallel to educational platforms, another solution has been developed for the acquisition of skills or theoretical knowledge, namely virtual or remote laboratories. As mentioned above, they allow students to operate on real or simulated instruments, no matter when or where they may find themselves. Unlike educational platforms, each and every time a virtual lab is created it is necessary to implement experiments on it, as well as those services and tools for the collaboration among students, the maintenance of learning material for practical assignments, etc. Neither reusing nor elearning standards are currently applied.

This thesis originated in the need for a software architecture or middleware with the capacity to merge both solutions into a single one which would allow: The students use of a single solution for the acquisition of theoretical and practical knowledge. The reuse of those services already offered by educational platforms, so that the designers of the remote laboratory may simply device and define the most suitable experiments for each lab. The reuse of e-learning standards supported by educational platforms, which involves reuse of courses, chapters or evaluation elements implemented by other institutions. The reuse of pre-existing labs, which saves institutions from going to the financial and personnel expense of developing the same laboratory. The creation of a global connective architecture of labs and learning management systems from different universities and institutions, as a global net of services.

NDICE GENERAL

CAPTULO 1. 1.1 1.2 1.3

INTRODUCCIN

Aprendizaje Electrnico o E-learning y Situacin Actual .................................... 1 Objetivo de este Trabajo .................................................................................... 2 Organizacin del Trabajo ................................................................................... 3

CAPTULO 2. 2.1 2.2 2.3 2.4

PLATAFORMAS EDUCATIVAS

Introduccin ....................................................................................................... 5 Plataformas Educativas ..................................................................................... 5 Sistemas de Gestin del Aprendizaje o LMS ..................................................... 7 Estndares e-learning ...................................................................................... 11 2.4.1 Comit de Entrenamiento Basado en Ordenador de la Industria de la Aviacin o AICC ........................................................................... 12 2.4.2 Dublin Core Metadata ........................................................................... 15 2.4.3 Fundacin ARIADNE ............................................................................ 17 2.4.4 Instituto de Ingenieros Elctricos y Electrnicos o IEEE ........................ 18 2.4.5 Consorcio de Aprendizaje Global IMS o IMS GLC ................................ 19 2.4.6 Aprendizaje Distribuido Avanzado SCORM o ADL SCORM.................. 38

2.5

Resumen ......................................................................................................... 47

CAPTULO 3. 3.1 3.2

SISTEMAS DE GESTIN DEL APRENDIZAJE

49

Arquitectura General de un Sistema de Gestin del Aprendizaje ..................... 49 .LRN ................................................................................................................ 51 3.2.1 Desarrollo de Aplicaciones o Paquetes ................................................. 56 3.2.2 aLF ....................................................................................................... 61

3.3

Moodle ............................................................................................................. 64 3.3.1 Servicios y Aplicaciones ofrecidas por Moodle ...................................... 65 3.3.2 Desarrollo de Mdulos y Bloques .......................................................... 68

XI

3.4

Sakai................................................................................................................ 77 3.4.1 Desarrollo de aplicaciones o herramientas .............................................. 79

3.5

Claroline .......................................................................................................... 80 3.5.1 Desarrollo de mdulos en Claroline ........................................................ 82

3.6 3.7 3.8

Plataformas Privadas ....................................................................................... 85 Comparativas entre LMS ................................................................................. 88 Resumen ......................................................................................................... 91

CAPTULO 4. 4.1 4.2

LABORATORIOS VIRTUALES Y REMOTOS

93

Introduccin ..................................................................................................... 93 Simulacin ....................................................................................................... 94 4.2.1 Creacin de un modelo ......................................................................... 94 4.2.2 Experimentacin sobre el modelo creado ............................................. 97

4.3 4.4

Definicin y Tipos de Laboratorios ................................................................... 98 Laboratorios Software .................................................................................... 102 4.4.1 Ventajas y Desventajas de los Laboratorios Software ......................... 102 4.4.2 Lenguajes de programacin y ejemplos de Laboratorios Software...... 104

4.5

Laboratorios Web........................................................................................... 107 4.5.1 Ventajas y Desventajas de los Laboratorios Web ............................... 107 4.5.2 Tecnologas Web utilizadas y ejemplos de laboratorios Web .............. 109

4.6

Laboratorios Remotos .................................................................................... 114 4.6.1 Ventajas y Desventajas de los Laboratorios Remotos......................... 116 4.6.2 Tecnologas Web utilizadas y ejemplos de laboratorios remotos ........ 117

4.7 4.8

Comparativa entre los diferentes tipos de laboratorios ................................... 124 Resumen ....................................................................................................... 125

CAPTULO 5. 5.1 5.2

ARQUITECTURA ILAB

127

Introduccin ................................................................................................... 127 Arquitectura para Compartir Laboratorios Online o iLab................................. 127

XII

5.3 5.4 5.5

Tipos de experimentos definidos en iLab ....................................................... 129 Ejemplo de utilizacin de iLab para experimentos batch ................................ 137 Resumen ....................................................................................................... 140

CAPTULO 6. 6.1 6.2

DISEO DE UNA ARQUITECTURA O MIDDLEWARE PARA LA INTEGRACIN DE LMS Y LABORATORIOS 141

Problemtica actual y necesidad de una nueva arquitectura .......................... 141 Diseo de la arquitectura ............................................................................... 145 6.2.1 Capa de Usuario ................................................................................. 145 6.2.2 Capa del LMS ..................................................................................... 148 6.2.3 El servidor del laboratorio ................................................................... 152 6.2.4 Middleware de comunicacin .............................................................. 152

6.3

Resumen ....................................................................................................... 161

CAPTULO 7. 7.1 7.2

IMPLEMENTACIN Y DESARROLLOS

163

Introduccin ................................................................................................... 163 Creacin de un paquete de laboratorio en LMS de cdigo abierto ................. 163 7.2.1 Desarrollo de un paquete para laboratorios virtuales y remotos en .LRN ................................................................................................... 163 7.2.2 Desarrollo de un mdulo de actividad en Moodle ................................ 182 7.2.3 Desarrollo del archivo view.tcl de dotLRN y view.php de Moodle ........ 189

7.3 7.4

Integracin de laboratorio en LMS de iniciativa privada (WebCT) .................. 190 Resumen ....................................................................................................... 191

CAPTULO 8. 8.1 8.2 8.3 8.4 8.5

EJEMPLOS PRCTICOS REALIZADOS

193

Introduccin ................................................................................................... 193 Ejemplo de utilizacin del paquete de dotLRN ............................................... 193 Ejemplo de utilizacin del mdulo de Moodle ................................................. 198 Ejemplo de utilizacin de WebCT y laboratorios ............................................ 200 Ejemplo de utilizacin del paquete SCORM ................................................... 202

XIII

8.6

Resumen ....................................................................................................... 203

CAPTULO 9. 9.1 9.2

CONCLUSIONES Y LNEAS DE INVESTIGACIN FUTURAS

205

Conclusiones y aportaciones ......................................................................... 205 Lneas de investigacin futuras ...................................................................... 208 9.2.1 Creacin de mdulos de otros LMS de cdigo abierto ........................ 208 9.2.2 aLF y Utilizacin de Laboratorios ........................................................ 208 9.2.3 Desarrollo de la arquitectura de comunicacin LMS y laboratorios ..... 209 9.2.4 Global Online Laboratory Consortium ................................................. 209 9.2.5 Sloodle y el mdulo de gestin de laboratorios ................................... 210 9.2.6 Creacin e implantacin de nuevos laboratorios en el DIEEC............. 211

CAPTULO 10. CURRICULUM VITAE DE ELIO SAN CRISTBAL RUIZ

213

CAPTULO 11. BIBLIOGRAFA

215

ANEXO 1. CONTENIDO DEL CD-ROM

227

XIV

GLOSARIO DE ACRNIMOS ADL ADP AGR Advanced Dustributed Learning (Aprendizaje Distribuido Avanzado) AOLserver Dynamic Pages (Pginas dinmicas de AOLserver) AICC Guidelines and Recommendations (Guas y Recomendaciones de AICC) AICC Aviation Industry CBT Committee (Comit de Entrenamiento Basado en Ordenador de la Industria de la Aviacin) AJAX AOLserver API Asynchronous JavaScript And XML (JavaScript y XML Asncrono) American Online server (Servidor de America Online) Application Programming Interface (Interfaz de Programacin de Aplicaciones) APM OpenACS Package Manager (Gestin Gestor de Paquetes de OpenACS) ARIADNE Alliance of Remote Instructional Authoring & Distribution Networks for Europe (Alianza de Autorizacin de la Enseanza remota y Redes de Distribucin para Europa) ASP CBT CLE Active Server Pages (Pginas Activas de Servidor) Computer-Based Training (Entrenamiento basado en ordenadores) Collaboration Colaborativo) CMI CMS Computer-Managed Instruction (Instruccin Gestionada por Ordenador) Content Management Systems (Sistemas de Gestin de Contenidos) Learning Environment (Entorno de Aprendizaje

XV

DAQ DOM

Data Acquisition (Adquisicin de Datos) Document Object Model (Modelo de Objetos para la representacin de Documentos)

ECMAScript

Application Programming Interface for Content to Runtime Services Communication

ESB ESS

Enterprise Service Bus (Bus de Servicios de Empresa) Experiment Storage Service (Servicio de almacenamiento de

experimentos) EVA FAQ GPIB HTML HTTP IEEE Espacios Virtuales de Aprendizaje (Learning Virtual Areas) Frequently Asked Questions (Preguntas ms Frecuentes) General Purpose Interface Bus (Bus de Interfaz de Propsito General). HyperText Markup Language (Lenguaje de Marcas de Hipertexto) HyperText Transfer Protocol (Protocolo de transferencia de Hipertexto) Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Elctricos y Electrnicos) IMS Innovation Adoption Learning (Innovacin para la Adopcin del Aprendizaje) IMS-CC IMS-CP IMS-LD IMS Common Cartridge (Cartucho Comn IMS) IMS Content Packaging (Empaquetado de contenidos IMS) IMS Learning Design (Diseo de Aprendizaje IMS)

XVI

IMS-LIS

IMS Learning Information Services (Servicios de informacin del aprendizaje IMS o IMS-LIS)

IMS-LTI

IMS Learning Tools Interoperability (Interoperabilidad de Herramientas de Aprendizaje IMS)

IMS-QTI

IMS Question & Test Interoperability Specification (Especificacin IMS para la Interoperabilidad de Tests y Preguntas)

ISA

iLab Shared Architecture (Arquitectura para Compartir Laboratorios Online)

JRE LAMS

Java Runtime Environment (Entorno de Ejecucin de Java) Learning Activity Managment System (Sistema de Control de

Actividades de Aprendizaje) LCMS Learning Content Management System (Sistemas de Gestin de Contenidos para el Aprendizaje) LD LDAP Learning Design (Diseo de Aprendizaje) Lightweight Directory Access Protocol (Protocolo Ligero de Acceso a Directorios) LMS LO LOM LSS Learning Management System (Sistemas de Gestin del Aprendizaje) Learning Object (Objeto de Aprendizaje) Learning Object Metadata (Metadatos de los Objetos de Aprendizaje). Lab-side Scheduling Service (Servicio de Planificacin del Lado del Laboratorio)

XVII

LTSC

Learning Technologies Standards Committee (Comit de Estndares en Tecnologas del Aprendizaje)

OpenACS

Open Architecture Community System (Sistema de Arquitectura Abierta de Comunidades)

PDF PHP REST

Portable Document Format, (Formato de Documento Porttil) PHP Hypertext Pre-processor Representational Representacional) State Transfer (Transferencia de Estado

RSS SCO SCORM

Really Simple Syndication (Sindicacin Realmente Sencilla) Sharable Content Object (Objeto Reutilizable de Aprendizaje) Shareable Content Object Reference Model (Modelo Referenciado de Objetos de Contenido Compartible)

SOA SOAP

Service Oriented Architecture (Arquitectura Orientada a Servicio) Simple Object Access Protocol (Protocolo de Simple de Acceso a Objetos)

SQL SSL TCL UDDI

Structured Query Language (Lenguaje de consultas estructuradas) Secure Sockets Layer (Protocolo de Capa de Conexin Segura) Tool Command Language (Herramienta de Lenguaje de Comandos) Universal Description, Discovery and Integration (Descripcin Universal, Descubrimiento e Integracin)

URI

Uniform Resource Identifier (Identificador Uniforme de Recurso)

XVIII

URL USS

Uniform Resource Locator (Localizador Uniforme de Recursos) User-side Scheduling Service (Servicio de Planificacin del Lado del Cliente)

VLE WADL

Virtual Learning Environment (Entornos Virtuales de Aprendizaje) Web Application Description Language (Lenguaje de Descripcin de Aplicaciones Web)

WS-BPEL

Business Process Execution Language (Lenguaje de Ejecucin de Procesos de Negocios con Servicios Web)

WSDL

Web Services Description Language (Lenguaje de Descripcin de Servicios Web)

WWW XML XQL

World Wide Web Extensible Markup Language (Lenguaje de Marcas Extensible) XML Query Language (Lenguaje de Consulta XML)

XIX

XX

LISTA DE TABLAS Tabla 2.1. Documentacin de SCORM 2004, 4Edicin. Tabla 3.1. Comparativa de herramientas de comunicacin de los LMS [Peris, 2008]. Tabla 3.2. Comparativa de tipos de preguntas disponibles de los LMS [Peris, 2008]. Tabla 3.3. Comparativa de estndares de LMS [Peris, 2008]. Tabla 4.1. Caractersticas de los diferentes tipos de laboratorios. Tabla 6.1. Comparativa Arquitectura REST y SOAP. Tabla 7.1. Parmetros de configuracin del portal. 39 89 90 90 124 155 176

XXI

XXII

LISTA DE FIGURAS

Figuras

Pginas

Figura 1. Figura 2. Figura 3. Figura 4. Figura 5. Figura 6. Figura 7. Figura 8. Figura 9.

Modelo Conceptual de EVA. [Covadonga, 2009]. ....................................... 7 Servicios proporcionados por los LMS. ....................................................... 8 Herramienta para la bsqueda de objetos de aprendizaje [ARIADNE, 2009]. ....................................................................................................... 18 Esquema Conceptual de LOM v1.0. ......................................................... 20 Modelo conceptual de un paquete de contenidos IMS v1.2 [IMS-CP, 2009]. ....................................................................................................... 22 Utilizacin de Child Manifest [IMS-CP, 2009]. ........................................... 24 Esquema IMS-LD [IMS-LD, 2009]............................................................. 26 Unidad de Aprendizaje [IMS-LD, 2009]. .................................................... 27 Esquema XML del elemento Assessment [IMS-QTI, 2009]....................... 28

Figura 10. Esquema XML del elemento section [IMS-QTI, 2009]............................... 28 Figura 11. Esquema XML del elemento Item [IMS-QTI, 2009]. .................................. 29 Figura 12. Estructura de un examen dentro de un paquete IMS [CNICE-MEC, 2009]. ....................................................................................................... 31 Figura 13. Entorno IMS-CC [IMS-CC, 2009]. ............................................................. 33 Figura 14. Fichero de intercambio paquete IMS-CC [IMS-CC, 2009]. ........................ 35 Figura 15. Autorizacin IMS-CC [IMS-CC, 2009]. ...................................................... 36 Figura 16. Arquitectura IMS-LTI [IMS-LTI, 2009]. ...................................................... 37 Figura 17. Arquitectura IMS-LIS [IMS-LIS, 2009]. ...................................................... 38 Figura 18. Assets [SCORM, 2004]. ............................................................................ 40 Figura 19. Actividades [SCORM, 2004]. .................................................................... 41 Figura 20. Organizacin de Aprendizaje [SCORM, 2004]. ......................................... 41 Figura 21. Agregacin de Aprendizaje [SCORM, 2004]. ............................................ 42 Figura 22. Ejemplo de SCO representado como un elemento <resource> [SCORM, 2004]. ....................................................................................... 43 Figura 23. Entorno de ejecucin SCORM [SCORM, 2004]. ....................................... 44 Figura 24. API SCORM [SCORM, 2004]. .................................................................. 45

XXIII

Figura 25. Transicin de Estados de una instancia de la API de SCORM [SCORM, 2004]. ....................................................................................... 46 Figura 26. rbol de actividad [SCORM, 2004]. .......................................................... 47 Figura 27. Arquitectura bsica de un sistema de gestin de aprendizaje. .................. 49 Figura 28. Relacin entre Aplicaciones y Servicios. ................................................... 50 Figura 29. Aplicaciones .LRN [dotLRN, 2009]. ........................................................... 52 Figura 30. Arquitectura dotLRN [dotLRN, 2009]. ....................................................... 57 Figura 31. Sistema de ficheros dotLRN. .................................................................... 57 Figura 32. Estructura de un paquete de OpenACS y dotLRN [OpenACS, 2009]. ...... 60 Figura 33. Paquetes, portlets y applets [Pesquera, 2009]. ......................................... 61 Figura 34. Interfaz de usuario de aLF. ....................................................................... 63 Figura 35. rea de contenidos con los portlets noticias, chat, grupos ........................ 63 Figura 36. Actividades, Recursos y Bloques Moodle [Moodle, 2009]. ........................ 67 Figura 37. Estructura del directorio Moodle. .............................................................. 69 Figura 38. Estructura del Fichero de un bloque Moodle. ............................................ 71 Figura 39. Carpeta /mod y mdulos de Actividad. ................................................... 75 Figura 40. Estructura de una actividad de Moodle. .................................................... 76 Figura 41. Curso Sakai. ............................................................................................. 78 Figura 42. Estructura de un paquete [Sakai, 2009]. ................................................... 80 Figura 43. Camino de aprendizaje. ............................................................................ 82 Figura 44. Estructura de directorios de claroline. ....................................................... 82 Figura 45. Instalacin de mdulos en Claroline. ........................................................ 85 Figura 46. Pgina inicial del Administrador en Blackboard Learn [Edugarage, 2009]. ....................................................................................................... 87 Figura 47. Pgina inicial del profesor en Blackboard Learn [Edugarage, 2009]. ........ 87 Figura 48. Pgina inicial de un estudiante en Blackboard Learn [Edugarage, 2009]. ....................................................................................................... 88 Figura 49. Clasificacin de modelos por A. J. Rowe [Shannon, 1988]. ...................... 95 Figura 50. Proceso de Simulacin [Shannon, 1988]. ................................................. 98 Figura 51. Servicios que normalmente rodean a un laboratorio Web o remoto. ....... 100

XXIV

Figura 52. Laboratorio Software. ............................................................................. 102 Figura 53. Laboratorio Software con descarga de versiones. .................................. 104 Figura 54. Entorno de trabajo de RCSim. ................................................................ 105 Figura 55. Entorno de trabajo de VLabQ. ................................................................ 106 Figura 56. Laboratorio Web. .................................................................................... 107 Figura 57. Modelo de Aplicaciones Web y de aplicaciones Web en AJAX [Garret, 2005]. ........................................................................................ 111 Figura 58. Puertas lgicas ofrecidas por el laboratorio web [Hopking, 2009]. .......... 112 Figura 59. Applet para el manejo del laboratorio web [Hopking, 2009]. ................... 112 Figura 60. Laboratorio Web hecho en Flash [Fisquiweb, 2009]. .............................. 113 Figura 61. Laboratorio Web hecho en Java. ............................................................ 113 Figura 62. Arquitectura general de un laboratorio remoto. ....................................... 114 Figura 63. Laboratorio Remoto WebLab-PLD de la universidad de Deusto. ............ 118 Figura 64. Arquitectura hardware de WebLab-Deusto [Ordua, 2007]..................... 119 Figura 65. Pgna HTML del Laboratorio Remoto [Lerro, 2008]............................... 120 Figura 66. Arquitectura Hardware del Laboratorio Remoto [Lerro, 2008]. ................ 121 Figura 67. Esquema de trabajo del Laboratorio Remoto [Lerro, 2008]. .................... 121 Figura 68. Workbench tradicional y on-line. ............................................................. 122 Figura 69. Implementacin de la mesa de trabajo on-line. .................................... 123 Figura 70. Planta Hidrulica de FESTO. .................................................................. 123 Figura 71. Arquitectura del laboratorio remoto de una planta hidrulica. ................. 124 Figura 72. Arquitectura iLab [ISA, 2010]. ................................................................. 128 Figura 73. Arquitectura de experimentos por lotes o batch [Hardward, 2004]. ......... 130 Figura 74. Diagrama de secuencia de la ejecucin de un experimento por lotes. .... 131 Figura 75. Comunicaciones necesarias en los experimentos por lotes e interactivos. ............................................................................................ 134 Figura 76. Arquitectura de experimentos interactivos [Hardison, 2008]. .................. 134 Figura 77. Acceso a iLab. ........................................................................................ 138 Figura 78. Lista de laboratorios disponibles para los usuarios invitados en iLab. .... 138

XXV

Figura 79. Pgina que aparece al seleccionar un laboratorio. ................................. 139 Figura 80. Cliente del laboratorio y cmara Web. .................................................... 139 Figura 81. Servicios proporcionados por los LMS y laboratorios. ............................. 143 Figura 82. Se libera de servicios al laboratorio y se reutilizan los del LMS. ............. 144 Figura 83. Middleware de Integracin. ..................................................................... 145 Figura 84. Caso de uso del administrador de .LRN para los laboratorios. ............... 146 Figura 85. Caso de uso del administrador del curso para los laboratorios. .............. 147 Figura 86. Caso de uso de un miembro de un curso en el LMS............................... 148 Figura 87. Modelo entidad-relacin de los usuarios y los chats del LMS. ................ 148 Figura 88. Creacin de un paquete en el LMS y de los servicios Web necesarios. ............................................................................................. 149 Figura 89. Modelo entidad relacin, bsico, del paquete. ........................................ 150 Figura 90. Patrn servicio-consumidor [Governor, 2009]. ........................................ 152 Figura 91. Estructura del mensaje SOAP. ............................................................... 154 Figura 92. Intercambio de mensajes SOAP a travs de HTTP. ............................... 154 Figura 93. Ejemplo de llamada a un servicio Web y respuesta. ............................... 155 Figura 94. Arquitectura SOA utilizando SOAP, WSDL y UDDI [ITProfessionals, 2009]. ..................................................................................................... 157 Figura 95. Ejemplo de proceso de negocio [SOAHowto, 2009]................................ 157 Figura 96. Utilizacin de un ESB, enrutamiento, transformacin y coreografa de servicios. ................................................................................................ 160 Figura 97. Arquitectura de dotLRN con el paquete entorno laboratorio.................... 164 Figura 98. Modelo de datos de dotLRN. .................................................................. 165 Figura 99. Modelo de datos de paquete entorno laboratorio de dotLRN. ................. 166 Figura 100. Estructura de un paquete de dotLRN. ..................................................... 167 Figura 101. Estructura de un fichero ADP de dotLRN................................................ 167 Figura 102. Estructura de un fichero TCL de dotLRN. ............................................... 168 Figura 103. Estructura de un fichero xql de dotLRN. ................................................. 169 Figura 104. Formulario para crear un paquete vacio. ................................................ 170

XXVI

Figura 105. Asociamos la URL o punto de montaje labs a nuestro paquete de dotLRN. .................................................................................................. 173 Figura 106. Diagrama de clases (dotlrn_community y dotlrn_laboratory). .................. 174 Figura 107. Diagrama E-R de dotlrn-laboratories y dotlrn_communities. ................... 174 Figura 108. Implementacin de los mtodos del paquete creado. ............................. 175 Figura 109. Diagrama completo del modelo de datos del paquete. ........................... 175 Figura 110. Llamadas de la callback creada a la API del paquete laboratorio. .......... 177 Figura 111. Diagrama de secuencia de labs::instantiate_and_mount. ....................... 177 Figura 112. Diagrama de secuencia de labs:new_edu_type_portal. .......................... 178 Figura 113. Portlet para visualizar el grupo Laboratories creado en dotLRN. ............ 179 Figura 114. Implementacin del caso de uso de gestin de laboratorios, administrador. ......................................................................................... 180 Figura 115. Implementacin del caso de uso de para los laboratorios, administrador grupo. ............................................................................... 181 Figura 116. Implementacin del caso de uso de para los laboratorios, miembro del grupo. ............................................................................................... 181 Figura 117. Modelo entidad relacin del mdulo de actividad curso. ......................... 184 Figura 118. Estructura del fichero install.xml. ............................................................ 185 Figura 119. Bloque de Administracin de Moodle. ..................................................... 187 Figura 120. Bloque de Administracin de Moodle modificado. ................................... 188 Figura 121. Opciones del administrador. ................................................................... 193 Figura 122. Formulario de creacin de un grupo laboratorio...................................... 194 Figura 123. Portal del laboratorio de electrnica, que pertenece al grupo laboratorios. ............................................................................................ 194 Figura 124. Pantalla para gestionar laboratories. ...................................................... 195 Figura 125. Portlet para aadir y borrar laboratorios de un curso. ............................. 196 Figura 126. Portlet del portal de estudiante y profesor con el listado de los laboratorios. ............................................................................................ 197 Figura 127. Acceso a los experimentos del laboratorio remoto de la universidad de Deusto. .............................................................................................. 197 Figura 128. Formulario para aadir un laboratorio en Moodle. .................................. 198 Figura 129. Seleccionamos la actividad wlab. ........................................................... 199

XXVII

Figura 130. Instancia del laboratorio remoto de la universidad de Deusto. ................ 199 Figura 131. Instancias de laboratorios en un curso Moodle. ...................................... 200 Figura 132. Acceso a los experimentos del laboratorio remoto de la Universidad de Deusto. .............................................................................................. 200 Figura 133. Creacin de la categora laboratorios en un curso de WebCT. ............... 201 Figura 134. Listado de laboratorios disponibles en un curso de WebCT.................... 201 Figura 135. Laboratorio Karnaugh del DIEEC (UNED) desde WebCT. ...................... 202 Figura 136. SCORM instalado en Moodle. ................................................................ 203 Figura 137. Reutilizacin de los servicios y estndares ofrecidos por los LMS en los laboratorios Web y remotos............................................................... 206

XXVIII

CAPTULO 1.

INTRODUCCIN

1.1

Aprendizaje Electrnico o E-learning y Situacin Actual

Segn la Real Academia de la Lengua, la palabra aprendizaje significa: Accin y efecto de aprender algn arte, oficio u otra cosa As, se puede decir que el aprendizaje electrnico es la accin y efecto de aprender algn arte, oficio u otro conocimiento utilizando medios electrnicos. La aparicin de estos medios electrnicos (PCs, mviles, etc), la mejora en las redes de comunicaciones, el avance de la multimedia y la aparicin de Internet han provocado un cambio en las metodologas de enseanza, dando impulso a otras, como:

Enseanza mixta, personalizada o blended learning. Es una mezcla de enseanza tradicional y a distancia.

Enseanza a Distancia. Cualquier persona desde cualquier lugar puede adquirir conocimiento. Actualmente existen un gran nmero de herramientas software que permiten obtener conocimiento desde un ordenador conectado a Internet (pginas web, wikis, etc.). Una de las herramientas ms utilizadas por las organizaciones para el aprendizaje son los sistemas de gestin del aprendizaje o LMS. Un LMS, entre otras caractersticas, permite:

Mostrar contenido de una forma organizada y controlada.

Proporcionar herramientas colaborativas (Chat, Foros, etc.)

Proporcionar estndares e-learning para reutilizacin de contenido, de evaluaciones, etc.

Los LMS estn centrados en la enseanza terica. Para la enseanza prctica se utilizan los laboratorios virtuales o remotos. Estos, ofrecen la posibilidad, a los estudiantes, de realizar sus prcticas y adquirir el conocimiento prctico que luego tendrn que aplicar en su trabajo. El problema actual es que ambas soluciones son independientes. Dando lugar a los siguientes problemas:

No reutilizan servicios. Cuando una organizacin crea un laboratorio, tambin crea un servicio de autenticacin, un servicio de almacn de ficheros, etc. Y no reutiliza los servicios ya disponibles en un LMS.

En general no utilizan los estndares e-learning soportados por los LMS.

En un principio no exista reutilizacin de laboratorios. Tampoco las universidades u organizaciones, en general, compartan sus laboratorios. El proyecto iLab del MIT desarroll una arquitectura para ello; pero dicha arquitectura no contempl la reutilizacin de servicios por parte de los laboratorios, ni la utilizacin de los servicios ofrecidos por los LMS.

1.2

Objetivo de este Trabajo

Este trabajo muestra una arquitectura o middleware para unir ambas soluciones (laboratorios e iLab con LMS) en una nica solucin, que permite reutilizar y compartir servicios, como autenticacin, herramientas de comunicacin, etc. Esta solucin permite:

Mostrar contenido de una forma organizada y controlada.

Herramientas colaborativas (Chat, Foros, etc.).

Estndares e-learning para reutilizacin de contenido, de evaluaciones, etc.

Seguimiento de los progresos del estudiante.

Realizacin de prcticas (simulacin o manejo de hardware real).

Reutilizacin de laboratorios de otras organizaciones y universidades.

1.3

Organizacin del Trabajo

Para explicar esta arquitectura y el progreso de su implementacin hemos dividido este trabajo en las siguientes secciones:

Situacin actual. o Plataformas educativas. Donde se explica detenidamente que es una plataforma educativa, que estndares e-learning existen y para que se utilizan. o Sistemas de Gestin de Aprendizaje. Se explica que es un LMS, que herramientas ofrecen y como, en el caso de LMS de cdigo abierto, es posible modificar o aadir servicios y herramientas. o Laboratorios Virtuales y Remotos. Se explican los tipos y arquitecturas que siguen los laboratorios y se analizan algunos de los ejemplos ms significativos. o Arquitectura iLab. Surgi de la necesidad de compartir laboratorios entre distintas universidades, pero no contempla la reutilizacin de servicios y la utilizacin de estndares e-learning.

Arquitectura Propuesta. Los captulos que forman esta seccin son:

o Diseo de una arquitectura o Middleware para la integracin LMS y Laboratorios. Se presenta la arquitectura y los elementos de la solucin planteada. o Implementacin y desarrollo, donde se describen las partes de la arquitectura que se han desarrollado. o Ejemplos prcticos. Se describe como utilizar los elementos de la arquitectura desarrollados mediante el desarrollo de ejemplos de implantacin.

Por ltimo, en el captulo conclusiones y lneas futuras se describen los trabajos futuros en los que se seguir trabajando para la ampliacin de dicha arquitectura.

CAPTULO 2.

PLATAFORMAS EDUCATIVAS

2.1

Introduccin

En 1962 R. Buckmister Fuller [Fuller, 1962] publica su visin de la enseanza y el aprendizaje con el ttulo Educacin Automtica, indicando que el futuro de la educacin estar fuertemente condicionado por la tecnologa, y se caracterizar por no tener lmites geogrficos, ni temporales. "Get the most comprehensive generalized computer setup with network connections to process the documentaries that your faculty and graduatestudent teams will manufacture objectively from the subjective gleanings of your vast new world and universe-ranging student probers." (p.85) Las plataformas e-learning, plataformas educativas o entornos virtuales de enseanza y aprendizaje (VLE), constituye una realidad tecnolgica, soportada por Internet, y que ofrece la posibilidad de proporcionar conocimiento en cualquier momento y en cualquier lugar donde haya una conexin a Internet. El uso de esta herramienta ha transformado una gran parte de los espacios de enseanza tradicionales en espacios virtuales de enseanza y aprendizaje (EVA) [Covadonga, 2009]. El objetivo de este captulo es dar una visin global para entender las plataformas y posteriormente dar a conocer algunas de las plataformas educativas ms utilizadas actualmente y los servicios que ofrecen.

2.2

Plataformas Educativas

Una plataforma e-learning, plataforma educativa web o entorno virtual de enseanza y aprendizaje, es una aplicacin web que integra un conjunto de herramientas para la enseanza-aprendizaje en lnea, permitiendo una enseanza no presencial (e-

learning) y/o una enseanza mixta (b-learning), donde se combina la enseanza por internet con experiencias en la clase presencial [Ramboll, 2004]. El principal objetivo de una plataforma de aprendizaje es la creacin y gestin de espacios de enseanza y aprendizaje (EA) en Internet, donde los profesores y los estudiantes puedan interaccionar durante su proceso de formacin [Covadonga, 2009]. Los EA son el lugares donde se realiza el conjunto de procesos de enseanza y aprendizaje dirigidos a la adquisicin de una o varias competencias [Griffiths, 2004]. As los espacios de aprendizaje pueden ser: Las aulas de un centro educativo, en la enseanza presencial. Los sitios en Internet, en la enseanza no presencial, virtual o e-learning. La combinacin de las aulas del centro y los sitios en Internet, enseanza mixta o b-learning. Un proceso de formacin o aprendizaje se puede organizar mediante un diseo de aprendizaje o LD, que se encarga de definir y planificar la actuacin de todos los elementos que participan en las relaciones didcticas: Rol de profesores y estudiantes Actividades que hay que realizar Escenarios Y relaciones entre roles, actividades y escenarios

Por tanto, se puede decir que un espacio de aprendizaje es donde se realizan los procesos de aprendizaje, los cuales estn definidos por diseos de aprendizaje. A

continuacin, la figura 1 muestra la relacin existente entre: entornos virtuales de aprendizaje, escenarios y diseos de aprendizaje.

Espacio Virtual de Aprendizaje Tiene

Escenarios 1..N Soporta

Diseo de Aprendizaje

Plataforma Educativa

Figura 1.

Modelo Conceptual de EVA. [Covadonga, 2009].

Actualmente el software ms utilizado para dar soporte a mltiples espacios virtuales de aprendizaje son los denominados sistemas de gestin del aprendizaje o LMS. En el siguiente apartado, se describir su estructura y funcionalidad.

2.3

Sistemas de Gestin del Aprendizaje o LMS

Un LMS es un software que permite mostrar contenido terico de una forma organizada y controlada. Para realizar esto un LMS permite crear y soportar mltiples espacios virtuales de aprendizaje, la creacin de estos EA, normalmente, se realizan utilizando una plantilla que permite al profesor, diseador del aprendizaje o administrador aadir un conjunto de herramientas que pueden considerar necesarias para el proceso de aprendizaje [Covadonga, 2009] [Horton, 2003] [Marcelo, 2006]. Estas herramientas y/o servicios estn disponibles en la mayora de las plataformas de aprendizaje o LMS, por lo que no es necesario programarlas una y otra vez (figura 2),

sino que se crean automticamente o pueden ser aadidos fcilmente por el administrador de un curso. A continuacin se vern algunas de los servicios y herramientas ms significativas:

Figura 2.

Servicios proporcionados por los LMS.

Herramientas de Administracin. Debe permitir a los administradores realizar las operaciones de creacin, borrado y modificacin de usuarios del sistema, definir roles, asignar tutores. As como llevar un control y seguimiento de los accesos al sistema. Por supuesto tambin debe permitir la creacin, borrado y modificacin de los espacios de aprendizaje que soporta.

Herramientas colaborativas o de comunicacin. Permiten la comunicacin y colaboracin entre los diferentes roles que hay en entorno de aprendizaje, como son: profesores, tutores, estudiantes, etc. La herramientas de comunicacin se dividen segn el tipo de interaccin temporal: o Si la interaccin profesor-estudiante, estudiante-estudiante, estudiantetutor, etc. requiere que ambos estn conectados al mismo tiempo, es decir se establece una comunicacin en vivo o en tiempo real se

denomina comunicacin sncrona. Algunos ejemplos de herramientas sncronas son: Chat, pizarra electrnica, audio y video conferencias. o Si la interaccin profesor-estudiante, estudiante-estudiante, estudiantetutor, etc. no requiere que ambos estn conectados al mismo tiempo, se denomina comunicacin asncrona. Algunos ejemplos de herramientas asncronas son: Correo electrnico o e-mail, foros, wikis, etc. Herramientas de almacenamiento de informacin y de gestin de contenidos. Los sistemas de gestin de contenido LMS se limitaban en un principio de un sistema de un sistema de almacenamiento y gestin de archivos que permiten realizar operaciones bsicas sobre ellos, como: visualizarlos, organizarlos en carpetas y subcarpetas, copiar, pegar o cargar archivos en el EA. En algunos casos se incluyen herramientas para la publicacin organizada de contenidos y algunas herramientas bsicas para la creacin de contenidos. En el prrafo anterior se ha hecho referencia a archivos. Existen otros tipos de software que complementan a los LMS en la gestin de contenidos, bien integrndose con el LMS o bien creando un hiperenlace en el LMS al espacio de aprendizaje que ellos crean. A continuacin se van a describir algunos de ellos: o Sistemas de gestin de contenidos o CMS. Son aplicaciones que permiten la creacin, almacenamiento indexado, clasificacin,

publicacin y gestin multiusuario y concurrente del ciclo de vida de los contenidos. Existen un gran nmero de CMS, y al igual que en los LMS, existen tanto iniciativas de carcter privado, como iniciativas de cdigo abierto

o Sistemas de gestin de contenidos para el aprendizaje o LCMS. Al igual que los CMS, proporcionan una gestin de contenidos, pero orientada al e-learning e integrando generalmente, generalmente, estndares elearning de produccin de contenidos educativos reutilizables como el paquete de contenidos IMS [IMS_CP, 2009] [Fallon, 2003] y SCORM [SCORM, 2004]. Los LCMS deben permitir [Fallon, 2003]: Generar descripciones nicas para cada objeto de aprendizaje. Descubrir (buscar y localizar) el objeto de aprendizaje requerido. Proporcionar mltiples jerarquas para el almacenamiento y organizacin de los objetos de aprendizaje. Facilitar la creacin de cursos

Herramientas de Evaluacin. Estas, permiten la creacin, edicin y realizacin de pruebas de evaluacin, trabajos, etc. Las pruebas pueden ser de autocorreccin, de tal forma que se el estudiante pueda afianzar o corregir posibles problemas que se le han presentado en el aprendizaje (feedback). Otra de las caractersticas de este tipo de herramientas es permitir al profesor hacer un informe o estadstica de las respuestas que han dado los estudiantes, y por tanto, ver en que partes del curso han encontrado mayor o menor dificultad de aprendizaje. Es importante mencionar que existen estndares e-learning para la creacin, edicin y reutilizacin de pruebas como: IMS-QTI [IMS_QTI, 2009] [Fallon, 2003]

10

Se ha visto que los LMS ofrecen un conjunto de herramientas que facilitan el proceso de aprendizaje. Tanto la adquisicin de conocimiento por parte del estudiante, como el seguimiento de los avances del estudiante por parte del profesor. Uno de los aspectos ms importantes de los LMS es el soporte de estndares e-learning. En el siguiente apartado se hablar de alguno de los ms importantes.

2.4

Estndares e-learning

Segn la Real Academia Espaola de la lengua, la palabra estndar significa: Que sirve como tipo, modelo, norma, patrn o referencia As, se puede decir, los estndar e-learning son patrones, modelos y/o reglas relacionados con el campo del aprendizaje electrnico. La utilizacin de estos estndares proporciona:

Contenidos reutilizables.

Migracin sencilla de un sistema a nuevas versiones, e incluso a una nueva plataforma.

Comunicacin e intercambio de informacin con otros sistemas.

Administracin de la informacin apropiada tanto del recurso como del estudiante.

Extensin de los servicios y de las capacidades de las plataformas.

La inversin en la infraestructura se asegura por mayor tiempo. Tambin, es importante distinguir entre dos tipos de estndares: estndares de jure y estndares de facto.

11

Estndares de jure, cuando provienen de una organizacin acreditada que certifica un patrn o modelo.

Estndares de facto, cuando un patrn o modelo se adoptan por un grupo mayoritario de individuos. A continuacin se describirn algunas de las iniciativas ms importantes y sus estndares e-learning ms significativos [Fallon, 2003].

2.4.1

Comit de Entrenamiento Basado en Ordenador de la Industria de la Aviacin o AICC

La industria de la aviacin ha sido tradicionalmente un gran consumidor de formacin, por lo que en 1992 se decidi crear un comit que desarrollase una normativa para sus proveedores de formacin basada en ordenador. De esta forma se garantizaba la armona entre los requisitos de los cursos, y la homogeneizacin de los resultados obtenidos en los mismos [AICC, 2009]. Los objetivos del AICC son:

Asistir a los operadores de aviones en el desarrollo de guas que promuevan la implementacin econmica y efectiva de CBT.

Desarrollar guas para permitir la interoperabilidad.

Proveer un foro abierto para la discusin de CBT y otras tecnologas de capacitacin. AICC desarrolla un conjunto de recomendaciones tcnicas (AGR), donde se abarca desde la entrega de contenidos hasta los dispositivos perifricos de un CBT. A continuacin se mencionarn cada una de ellas:

AGR

001-

AICC

Publications.

Este

documento

resume

todas

las

recomendaciones publicadas por AICC.

12

AGR

002-

Courseware

Delivery

Stations.

Este

documento

contiene

recomendaciones para la industria de aviacin en la adquisicin de estaciones de entrega de cursos (CBT) a los estudiantes. AGR 003- Digital Audio: Este documento contiene recomendaciones que promueven la interoperabilidad de audio digital.

AGR 004- Operating/Windowing System: Este documento proporciona una recomendacin formal para la industria de aviacin en sistemas operativos utilizados para la entrega de CBT.

AGR 005- CBT Peripheral Devices: Este documento contiene recomendaciones que promueven la interoperabilidad de los siguientes dispositivos perifricos: tarjetas de video, reproductores de video, dispositivos de entrada XY (como pantallas tctiles, ratones, etc), etc.

AGR 006- Computer-Managed Instruction o CMI: Este documento contiene recomendaciones que promueven la interoperabilidad de sistemas CMI. Es decir, la habilidad de que un CMI gestione lecciones CBT desde diferentes orgenes.

AGR

007-

Courseware

Interchange:

Este

documento

contiene

recomendaciones para el intercambio de elementos (texto, grficos, audio, etc.) que se encuentran dentro de un curso CBT.

AGR 008- Digital Video: Este documento contiene recomendaciones para la creacin, distribucin y utilizacin de video digital en cursos CBT.

AGR 009- Icon Standards. User Interface: Este documento contiene recomendaciones para las funciones de la interfaz de usuario/estudiante y su representacin grfica asociada en un curso CBT

13

AGR 010- Web-Based Computer-Managed Instruction: Este documento contiene recomendaciones que promueven la interoperabilidad de sistemas CMI basados en Web.

AGR011- CBT Package Exchange Notification: Este documento contiene recomendaciones que promueven un medio de simplificar la transferencia de paquetes de contenido entre sistemas.

AGR012- Training Development Checklist: Identificar aspectos vitales de un programa de entrenamiento/CBT de calidad. Aunque el AICC ha publicado varias guas, la ms seguida es la AGR 010 que habla de la Interoperabilidad de las plataformas de formacin y los cursos. En esta gua se resuelven dos de los problemas fundamentales: 1. La carga sin problemas en un LMS de cursos creados por terceros. Este objetivo se consigue definiendo el curso como una entidad totalmente independiente de la plataforma, y creando un sistema (ficheros) de descripcin del curso que pueda ser entendido por cualquier plataforma. 2. La comunicacin entre el LMS y el curso, de tal modo que el curso pueda obtener informacin necesaria sobre el usuario, y despus transmitir los resultados de las interacciones y evaluaciones realizadas por el mismo a la plataforma a fin de su almacenamiento y tratamiento estadstico. Este segundo objetivo es logrado mediante la definicin de un mecanismo de comunicacin entre el curso y la plataforma, y un conjunto de datos mnimos que deben ser transmitidos del curso a la plataforma y viceversa. La AICC describe dos mecanismos, uno ms sencillo y extendido basado en el protocolo HTTP, y otro mediante una API.

14

El AICC cuenta con un programa de certificacin y dispone de un test suite que le permite a las compaas verificar que sus productos son compatibles con otros sistemas que cumplen con las especificaciones AICC. La AGR 010 del AICC es un estndar de facto en la industria del e-learning.

2.4.2

Dublin Core Metadata

Antes de comenzar con esta y otras iniciativas conviene decir que un metadato, en ingls metadata, son datos que describen otros datos. As, la iniciativa de metadatos Dublin Core proporciona un estndar simple para facilitar la bsqueda, comparticin y gestin de informacin. Lo que hace es establecer un conjunto de elementos que permitan describir recursos de informacin. En la dcada de los 90 se describieron 15 elementos (RFC2413) que permitan describir recursos de informacin. Estos elementos se clasificaron en tres grupos:

Contenidos. Son elementos relacionados con el tipo de recurso. o Ttulo, etiqueta: Title. o Tema del recurso, etiqueta: Subject. o Descripcin del contenido del recurso, etiqueta: Description. o Categora del recurso (informe, libro, etc.), etiqueta: Type. o Fuente, indica una segunda fuente donde se presenta el contenido, etiqueta: Source. o Un identificador al segundo recurso y su relacin con la fuente actual, etiqueta: Relatiotion.

15

o Hace referencia a la caracterstica fsica y temporal del contenido intelectual del recurso, etiqueta: Coverage.

Propiedad intelectual. Son elementos relacionados con la propiedad intelectual del recurso. o Persona u organizacin responsable de la creacin del contenido intelectual del recurso, etiqueta: Creator. o La entidad responsable de hacer que el recurso est disponible, etiqueta: Publisher. o Personas que han contribuido de alguna forma en el contenido intelectual del recurso, etiqueta: Contribuitor. o Derechos sobre el contenido, etiqueta: Rights.

Instanciacin. Son los elementos relacionados con la instanciacin del equipo. o Fecha asociada con la creacin o disponibilidad del recurso, etiqueta: Date. o Formato de los datos, etiqueta: Format. o Identificador nico, etiqueta: Identifier. o El lenguaje del contenido intelectual del recurso, etiqueta: Language. Actualmente, el panorama de los metadatos, segn Dublin Core se caracteriza en trmino de cuatro niveles de interoperabilidad de aplicaciones, que recibe el nombre de marco de trabajo de Singapore para perfiles de aplicaciones Dublin Core: 1. Nivel 1. Definiciones de trminos compartidos. Vocabularios compartidos, definidos en lenguaje natural.

16

2. Nivel 2. Interoperabilidad de semntica formal. Vocabularios compartidos, basados en semnticas formales. 3. Nivel 3. Interoperabilidad de un conjunto de descripciones sintcticas. Vocabularios compartidos formales en el intercambio de registros de metadatos. 4. Nivel 4. Interoperabilidad de un conjunto de descripciones de perfiles. Vocabularios y restricciones compartidas formales en el intercambio de registros de metadatos. Los metadatos de Dublin Core se han convertido en uno de los estndares ms extendidos en la recuperacin de informacin en la World Wide Web o WWW.

2.4.3

Fundacin ARIADNE

La fundacin ARIADNE es una asociacin europea abierta al mundo para compartir y reutilizar el conocimiento. Fue creada para explotar y desarrollar los resultados de los proyectos europeos ARIADNE y ARIADNE II, en los cuales se crearon herramientas y metodologas para producir, gestionar y reutilizar elementos pedaggicos basados en ordenador. As como la utilizacin de los canales telemticos adecuados para los programas de formacin [ARIADNE, 2009]. Uno de las herramientas que proporciona ARIADNE es una herramienta de indexacin y bsqueda de objetos de aprendizaje. Esta herramientas es un middleware que permite la bsqueda de objetos de aprendizajes en varios repositorios (GLOBE [GLOBE, 2009], ProLearn [ProLearn, 2009], etc.) (figura 3). De esta forma cualquier repositorio de objetos podra conectarse a ARIADNE, siguiendo una arquitectura de conexin o middleware.

17

Figura 3.

Herramienta para la bsqueda de objetos de aprendizaje [ARIADNE, 2009].

2.4.4

Instituto de Ingenieros Elctricos y Electrnicos o IEEE

El instituto de ingenieros elctricos y electrnicos o IEEE, es la mayor asociacin internacional, sin nimo de lucro, formada por profesionales de ingeniera y otros campos. Su objetivo es fomentar la innovacin tecnolgica y la excelencia para el beneficio de la humanidad [IEEE, 2009], Para llevar a cabo este objetivo, el IEEE ofrece numerosas oportunidades profesionales y educativas, como:

Publicaciones tcnicas en ingeniera elctrica, informtica, electrnica, etc.

Librera digital. Que contiene ms de dos millones de documentos del IEEE, artculos publicados en revistas, conferencias, etc. y estndares del IEEE activos.

Conferencias. Donde cada ao, ms de 100.000 profesionales se renen en ms de 900 conferencias.

Estndares. Donde el IEEE ha desarrollado y desarrolla algunas de las normas ms importantes de las telecomunicaciones de hoy en da, la tecnologa de la educacin y los productos de la generacin de energa y servicios.

18

Ms adelante, se describir brevemente uno de los estndares ms conocidos y utilizados en el campo del e-learnig y que recibe el nombre de metadatos de objetos de aprendizaje o LOM.

Actividades educativas. Donde se pueden realizar cursos online o presenciales, obtener acreditaciones profesionales, etc. Para llevar a cabo estas y otras tareas, el IEEE se divide en seis consejos o asociaciones, estas, a su vez, se dividen en comits tcnicos y grupos de trabajo. Una de estas asociaciones es la de estndares y uno de sus comits, es el Comit de Estndares en Tecnologas del Aprendizaje o LTSC [LTSC, 2009]. El LTSC desarrollo el estndar de metadatos para los objetos de aprendizaje o LOM. Este estndar se encarga de definir un esquema conceptual de datos (XML), que permite describir objetos de aprendizaje (figura 4). Y por tanto facilita la bsqueda, evaluacin, adquisicin y utilizacin de los objetos educativos [Anido, 2002]. El estndar LOM de IEEE es un estndar de jure. Adems de este estndar e-learning IEEE trabaja en otros estndares como: Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata.

2.4.5

Consorcio de Aprendizaje Global IMS o IMS GLC

El consorcio de aprendizaje global IMS est representado por ms de 140 organizaciones miembro como Blackboard, IBM, California State University Systems, etc. Y cuya finalidad es proporcional un foro neutral en el que sus miembros trabajen juntos para promover el uso de la tecnologa en el apoyo y transformacin del aprendizaje.

19

Identificador General Ttulo Idioma Descripcin Palabra Clave 1. General mbito Estructura Nivel de Agragcin Catlogo Entrada

Versin Estado Tipo Contribucin Entidad Fecha Identificador 3. MetaMetadatos Contribucin Esquema de Metadatos Idioma Catlogo Entrada Tipo Entidad Fecha

2. Ciclo de Vida

Learning Object Metadata

Entidad Fecha Descripcin

8. Anotacin

Proposito Fuente 9. Clasificacin Ruta Taxonmica Descripcin Palabras Clave Taxn Identificador Entrada

Figura 4.

Esquema Conceptual de LOM v1.0.

20

En este apartado se mencionarn y describirn algunos de los estndares e-learning creados por IMS y que han adquirido una gran importancia, bien el campo del aprendizaje electrnico o como complemento a otros estndares.

Empaquetado de contenidos IMS o IMS-CP

Diseo de aprendizaje IMS o IMS-LD

Interoperabilidad test y cuestiones IMS o IMS-QTI

Cartucho comn IMS o IMS-CC

Interoperabilidad de herramientas de aprendizaje IMS o IMS-LTI

Servicios de informacin del aprendizaje IMS o IMS-LIS Todas estas especificaciones estn descritas en el lenguaje de modelado universal o UML [Jacobson, 2005] [Jacobson, 1999] y posteriormente descritas en XML. Empaquetado de contenidos IMS o IMS-CP La especificacin IMS-CP versin 1.2 describe las estructuras de datos que pueden ser utilizadas para intercambiar datos entre sistemas que desean importar, exportar, agregar y desglosar paquetes de contenido. Esta especificacin permite exportar contenido desde un LMS o repositorio digital e importarlo en otro [IMS-CP, 2009]. La estructura de un paquete de contenidos IMS v1.2 (figura 5), est formada por:

Paquete lgico. Es una representacin de una o ms unidades de uso (y reutilizables) de contenido. El paquete abarca el conjunto completo de elementos descritos por el Manifest, incluyendo los componentes locales y remotos mediante referencia.

21

Paquete Lgico
Paquete de Intercambio MANIFEST
Metadatos Organizaciones Recursos Child Manifest Metadatos externos Manifests externos Paquetes de intercambio externos

Ficheros externos FILES E.g., media, evaluaciones, colaboraciones, ficheros de control, ...

Figura 5.

Modelo conceptual de un paquete de contenidos IMS v1.2 [IMS-CP, 2009].

Paquete de intercambio. Es el conjunto de componentes que pueden ser intercambiados entre sistemas, incluyendo el Manifest y otros archivos seleccionados

Manifest. Es el componente que describe una instancia completa de un paquete lgico. Puede contener referencias a componentes que son locales y remotos. Se utiliza XML como lenguaje para describir una instancia del paquete lgico

Organizaciones. Son relaciones lgicas entre unidades de contenido. Pueden describirse ms de una relacin lgica.

22

Recursos. Un inventario de los contenidos y ficheros utlizados por el Manifesr. Los ficheros pueden ser locales o remotos.

Child-Manifests. Son Manifest completos o subordinados que estn contenidos dentro del Manifest o referenciados desde el Manifest. Cada uno de ellos describe un paquete lgico completo, que a su vez, forman parte de un paquete lgico mucho mayor. Los child-manifests pueden ser locales y remotos (figura 6).

Ficheros. Incorporan el contenido descrito por el paquete lgico o regulan la unin de otros ficheros para hacerlos adecuados al procesamiento de la maquina. Los ficheros de contenido pueden ser locales o remotos.

Metadatos.

Informacin

descriptiva

sobre

paquetes

de

contenido,

organizaciones locales, contenidos o ficheros. En muchos casos los paquetes de contenido son creados por profesores o personas que no conocen el lenguaje XML. Para facilitar la creacin y modificacin de paquetes de contenido IMS, han aparecido un conjunto de editores que permiten realizar estas operaciones de manera visual e intuitiva. Uno de los ms utilizados es RELOAD [Reload, 2009]. Diseo de aprendizaje IMS o IMS-LD El objetivo de IMS-LD es permitir una gran variedad de diseos educacionales, usando una notacin consistente, que puede ser instalada en mltiples cursos o programas de aprendizaje [IMS-LD, 2009]. Por tanto es necesario:

Describir e implementar diferentes tipos de enfoques de aprendizaje.

Permitir que las unidades de aprendizaje sean eficaces y eficientes.

23

Permitir el acceso e intercambio de unidades de aprendizaje en sistemas de aprendizaje.

Manifest Anidados

Manifest referenciados

MANIFEST (ejemplo1) Organizaciones Organizacin Item Item Item Recursos MANIFEST (ejemplo2) Organizaciones Organizacin Item Item Item Recursos Recurso Recurso

MANIFEST (ejemplo1) Organizaciones Organizacin Item Item Item Recursos Ipointer Ipointer

MANIFEST (ejemplo2) Organizaciones Organizacin Item Item Item Recursos Recurso Recurso

MANIFEST (ejemplo3) Organizaciones Organizacin Item Item Item Recursos Recurso Recurso

MANIFEST (ejemplo3) Organizaciones Organizacin Item Item Item Recursos Recurso Recurso

Figura 6.

Utilizacin de Child Manifest [IMS-CP, 2009].

Soportar mltiples modelos de entrega

Soportar reutilizacin y reformulacin de las unidades de aprendizaje o de sus componentes.

24

Soportar mltiples estudiantes y roles de una actividad de aprendizaje, reflejando las experiencias de aprendizaje que requieren colaboracin o que estn enfocadas a realizarse en grupo. Como se puede observar IMS_LD toca aspectos educacionales (alcance,

secuenciacin de actividades de aprendizaje, roles, etc.) (figura 7) y no se limita a la descripcin de un objeto de aprendizaje, como IMS-CP, por lo que se complementan para crear una unidad de aprendizaje (figura 8). As, IMS-LD ha sido dividida en tres partes conocidas como: nivel A, nivel B y nivel C.

Nivel A. Contiene el vocabulario bsico necesario que soporta la diversidad pedaggica. Los niveles B y C aaden nuevos conceptos y capacidades para soportar comportamientos de aprendizaje ms sofisticados.

Nivel B. Aade propiedades y condiciones al nivel A, permitiendo la personalizacin, una secuenciacin ms elaborada e interacciones basada en carteras de estudiantes o Potfolios. Puede ser utilizado para dirigirlas actividades de aprendizaje as como registrar los resultados. Es importante indicar que la separacin de estas propiedades y condiciones en un esquema independiente permite que pueda ser utilizado de forma independiente del resto de especificaciones de diseo del aprendizaje.

Nivel C. Agrega al nivel B la posibilidad de realizar notificaciones. La creacin de IMS-LD es complicada, para facilitar la creacin y modificacin de estos esuqema, han aparecido un conjunto de editores que permiten realizar estas operaciones de manera visual e intuitiva. Uno de los ms utilizados es RELOAD [Reload, 2009].

25

Figura 7.

Esquema IMS-LD [IMS-LD, 2009].

26

Paquete IMS MANIFEST

Metadatos Organizaciones Recursos Child Manifest

Unidad de Aprendizaje MANIFEST

Metadatos

+ IMS Learning Design =

Organizaciones: Learning Design Recursos Child Manifest

FILES E.g., media, evaluaciones, colaboraciones, ficheros de control, ...

FILES E.g., media, evaluaciones, colaboraciones, ficheros de control, ...

Figura 8.

Unidad de Aprendizaje [IMS-LD, 2009].

Interoperabilidad test y cuestiones IMS o IMS-QTI La especificacin IMS-QTI describe un modelo de datos para la representacin de cuestiones (assessmentItem) y test (assessment) con sus correspondientes informes de resultados. As, esta especificacin permitir el intercambio de cuestiones, test y resultados entre sistemas de aprendizaje, sistemas de entrega de evaluaciones, etc. A continuacin se mencionarn algunos de los objetos de esta especificacin y su comportamiento:

Assessment. Es el objeto que representa la estructura de datos de evaluacin (figura 9).

Section. Es el objeto que representa la estructura de datos de seccin (figura 10).

27

Figura 9.

Esquema XML del elemento Assessment [IMS-QTI, 2009].

Figura 10.

Esquema XML del elemento section [IMS-QTI, 2009].

Item. Es el objeto que representa la estructura de datos Item o cuestiones (figura 11).

28

Figura 11.

Esquema XML del elemento Item [IMS-QTI, 2009].

A parte de estos objetos existen otros objetos que permiten interaccionar con la pregunta, darles peso a las puntuaciones, presentar los contenidos y posibles preguntas. o Activity Selection. Seleccin de la siguiente actividad determinada por el progreso y resultados obtenidos hasta el momento de la seleccin de la actividad. o Outcomes Processing. la recopilacin de todas las salidas de evaluacin para producir una evaluacin global de la evaluacin de Assessment/Section. o Scoring Weights. Los pesos de las puntuaciones que son asignadas a las respuestas.

29

o Response Processing. El procesamiento y evaluacin de las respuestas de usuario. o Presentation. Presenta los contenidos y las posibles respuestas. o Examinee Record. El conjunto de resultados cotejados que es la salida del proceso completo. Este es un registro persistente que contiene los progresos histricos de los evaluados. o Outcomes. El conjunto de resultados que son evaluados por el objeto processing object. Estos determinan las mtricas de puntuacin que son aplicadas a las evaluaciones. o Response. Las respuestas seleccionadas por el usuario de los items. o Flow. la estructura de presentacin subyacente que define los bloques de relacin entre los diferentes componentes de material. o Material. El contenido que va a ser mostrado. Por tanto, un examen para IMS QTI es simplemente un grupo de preguntas. Durante el proceso de creacin podemos estructurar el examen en distintas partes (testPart). Por ejemplo, si hemos impartido un mdulo de un curso en el cual se discuten distintos temas, podemos crear un examen en el que se crean distintas partes por cada uno de esos temas. Asimismo, estas partes pueden dividirse en distintas secciones (sections) que representan diferentes secciones dentro de una parte del examen. Tanto las partes como las secciones de un examen pueden contener materiales que sern presentados a los estudiantes durante la realizacin de dicha parte o seccin (figura 12) [CNICE-MEC, 2009]. El objetivo de las partes del examen es doble:

30

Desde el punto del estudiante, cuando realice el examen se le presentarn cada una de las partes en las que est dividido el examen en el orden en el que aparecen en la definicin del examen.

Desde el punto de vista del creador del examen, el uso de distintas partes, permite configurar distintas partes del examen, por ejemplo, indicando alguna limitacin en el tiempo que puede emplear un estudiante en una parte o seccin.

Paquete de contenido IMS

Testpart

Assessment Exmen testPart testPart

Section1

Section2

Section1a

Secton2a

Secton2b

testPart
Q1 Qn

Pregunta1 Pregunta2

Pregunta3 Pregunta n

Figura 12.

Estructura de un examen dentro de un paquete IMS [CNICE-MEC, 2009].

Adems de la estructuracin, un objetivo adicional es la generacin de una nica evaluacin, es decir, de una nota que agrupe todas las evaluaciones individuales de las preguntas, ponderndolas con algn factor si fuera necesario. Para ello, durante la creacin del examen se puede definir cmo ha de realizarse la agrupacin de las evaluaciones individuales. Tambin hay que destacar que desde el punto de vista de QTI la creacin de un examen se realiza de manera completamente independiente de las preguntas de las

31

que est compuesto. Al intercambiar un examen entre la herramienta de autora y la herramienta que interpreta la descripcin del examen, este intercambio se realiza creando un paquete de intercambio definido mediante el uso de la especificacin IMSCP. Se acaba de ver que IMS_QTI est relacionado con los paquetes de contenidos IMS. Esta especificacin se relaciona con ms estndares como:

IEEE LOM. Al igual que el resto de contenidos educativos, es necesario la inclusin de metainformacin que permita clasificar los contenidos. En el caso de las preguntas y exmenes la metainformacin es muy til a la hora de almacenar las preguntas dentro de los bancos de preguntas, de manera que podramos clasificar las preguntas segn materias y dificultades, facilitando la bsqueda dentro de dichos repositorios y la posible generacin automtica de exmenes.

IMS-LD. En el nivel B de la especificacin se hace uso de las condiciones para poder modificar la Unidad de Aprendizaje. Una posible actividad en una Unidad de Aprendizaje puede ser la realizacin de un examen, donde la puntuacin de este examen ser almacenada en alguna propiedad de la Unidad de Aprendizaje, de manera que el cambio de esta propiedad afecta a las condiciones y por tanto condicionar la puesta en prctica de otras actividades. Existen herramientas que permiten la creacin, modificacin y gestin de exmenes, uno de ellas es Respondus [Respondus, 2009.] Cartucho comn IMS o IMS-CC Esta especificacin define un formato abierto para la distribucin de contenido enriquecido basado en web (html, xml, enlaces Web, ficheros multimedia, ficheros de aplicaciones (por ejemplo office)) que permita el intercambio de paquetes entre los

32

LMS que soporten dicha especificacin (figura 13). Para ello define un perfil de las siguientes especificaciones:

IEEE LOM, Dublin Core.

Paquete de contenidos IMS o IMS-CP v1.2.

Interoperabilidad test y cuestiones IMS o IMS-QTI v1.2.1 (mltiple eleccin, verdadero/falso, ensayos, preguntas de rellenar los espacios en blanco y preguntas de relacionar conceptos).

Servicios web de autorizacin IMS v1.0.

Servicios

CMS

Servidor Web

Servidor e-book

Servidor de Aplicaciones Web

Servidor de Autenticacin

LMS
Evaluaciones QTI

XML rendering

Enlaces Web

Base de datos LMS Common Cartridge

Autorizacin

Common Cartridge

Foros

Funcin de Importar

Run Time

LTI

Funcin Exportar

Estudiante

Servicios de informacin Institucional

Servicios de informacin de estudiantes Librera de servicios

Figura 13.

Entorno IMS-CC [IMS-CC, 2009].

A continuacin se describir los tipos de contenidos de IMS-CC:

33

Item-Folder. Una carpeta o folder representa una unidad de organizacin. Una carpeta es una coleccin de elementos o tems y subcarpetas que siguen un orden Recurso Contenido Web. Los ficheros de contenido Web incluyen cualquier fichero que puede ser entregado sobre la Web (ficheros HTML, imgenes, audio, video, MS office, PDF, Flash, etc.). Recurso Enlace Web representa un objeto de aplicacin de aprendizaje. Es enlace HTTP estndar. Recurso Tema de Discusin. Un tema de discusiones un objeto de aplicacin del aprendizaje que es utilizado para iniciar una discusin. El LMS espera generar un nuevo tema de discusin usando solo sus herramientas internas. Ello contiene los siguientes atributos: ttulo, descripcin ficheros adjuntos. Recurso Evaluacin. Una evaluacin representa una instancia de una evaluacin QTI. Una evaluacin puede contener un nmero de atributos como: nmero de intentos, lmite de tiempo, etc. Recurso Contenido Asociado Es una coleccin de ficheros usados exclusivamente por un objeto de aplicacin de aprendizaje.

Referencia interna de paquetes. Esto permite que los objetos de aplicacin de aprendizaje o ficheros que se encuentran en el paquete puedan referenciar a otros ficheros que tambin estn dentro del paquete.

Paquete de Metadatos IMS-CC. Son metadatos al nivel del paquete IMS-CC y puede contener informacin acerca de: accesibilidad, descripcin, etc.

Banco de Preguntas. Puede incluirse, de forma opcional, un banco de preguntas dentro de IMS-CC.

34

Se ha descrito cada uno de los contenidos que puede contener el paquete de intercambio IMS-CC (figura 14). Uno de las palabras ms utilizadas, en esta enumeracin, ha sido Objeto de aplicacin de aprendizaje, se puede describir este objeto como:

Una estructura de directorio utilizada para agrupar todos los ficheros o referencias a ficheros que son utilizados para entregar una nica instancia de uno de los siguientes recursos: contenido web, enlace web, tema de discusin, evaluacin o referencia interna de paquetes.

Cartucho
MANIFEST
Metadatos del Cartucho Metadatos de los Roles Contenido Web del cartucho Carpeta de elementos (item folder) Recurso contenido Web Recurso enlace Web

Carpeta Objeto de Aplicacin de Aprendizaje

Recurso tema de discusin Recurso evaluacin

Objeto de aplicacin de aprendizaje 1 Recursos

Recurso Referencia

interna de paquetes

Objeto de aplicacin de aprendizaje 1 Contenido Asociado

Carpeta Objeto de Aplicacin de Aprendizaje

Objeto de aplicacin de aprendizaje n Recursos

Objeto de aplicacin de aprendizaje n Contenido Asociado

Banco de Preguntas

Carpeta

Fichero

Figura 14.

Fichero de intercambio paquete IMS-CC [IMS-CC, 2009].

Otro de los aspectos importantes es la autorizacin a travs de servicio web. As, un cartucho comn incluir la informacin requerida por el LMS para comunicarse con el

35

servicio de autenticacin proporcionado por el editor del cartucho. Cuando un usuario intenta acceder o importar el contenido del cartucho protegido, el LMS le pedir al usuario un cdigo de acceso. El LMS, luego utiliza el servicio (SOAP) para enviar al publicador del cartucho el cdigo de acceso y un identificador nico para el cartucho al que se accede. El sistema publicador del cartucho intentar validar la informacin proporcionada. Si la informacin es vlida, el servicio responder con un cdigo de xito y, opcionalmente, una fecha de caducidad. Si la informacin se considera no vlida, un cdigo de error se devuelve junto con una descripcin legible del por qu se rechazaron las credenciales (figura 15).

Sistema de gestin del Aprendizaje

Estudiante

Importar Cartucho

Servicio Web de Autorizacin (SOAP) Servicio de Autorizacin

Figura 15.

Autorizacin IMS-CC [IMS-CC, 2009].

Interoperabilidad de herramientas de aprendizaje IMS o IMS-LTI IMS-LTI est dirigida a la utilizacin de un mecanismo reutilizable para integrar herramientas de terceros con sistemas de gestin de aprendizaje. Tambin es un complemento a IMS-CC ya que permite acceder aplicaciones o herramientas basadas en web. A continuacin se describirn brevemente algunos de los componentes ms importantes de la arquitectura IMS-LTI [IMS-LTI, 2009] (figura 16).

36

Herramienta Proxy. Es un proxy o facade en el LMS, para su asociacin real con herramientas. La arquitectura define un mecanismo estndar para empaquetamiento de herramientas proxy que permita desplegarse a un LMS.

Entorno

de

ejecucin

interoperable.

Es

una

coleccin

de

servicios

implementados mediante un contenedor que permiten a las herramientas proxy: ser desplegada, configurada y ejecutada desde dentro del contenedor.

CAPA CLIENTE
Contenedor Herramienta de Aprendizaje

LMS
Entorno ejecucin interoperable

Herramienta 1
Entorno ejecucin interoperable

Servicios Web

Despliegue del servicio Configuracin del servicio Lanzar el servicio

Herramienta proxy 1

Herramienta proxy 2

Herramienta 2
Entorno ejecucin interoperable

Paquete Herramienta Proxy 1

Paquete Herramienta Proxy 2

Figura 16.

Arquitectura IMS-LTI [IMS-LTI, 2009].

Servicios de informacin del aprendizaje IMS o IMS-LIS La especificacin de servicios de informacin del aprendizaje IMS es la definicin de cmo los sistemas gestionan el intercambio de informacin que describe grupos, miembros, cursos y los resultados en el contexto del aprendizaje (figura 17) [IMS-LIS, 2009].

37

Sistemas

Servicios Web LIS

Figura 17.

Arquitectura IMS-LIS [IMS-LIS, 2009].

2.4.6

Aprendizaje Distribuido Avanzado SCORM o ADL SCORM

La iniciativa ADL, desarrolla e implementa tecnologas de aprendizaje a travs del Departamento de Defensa de los Estados Unidos de Amrica y el gobierno federal [ADL, 2009]. Uno de los estndares ms utilizados en el aprendizaje electrnico, desarrollado por ADL, es la especificacin relacionada con objetos SCORM. Se puede decir que SCORM, describe la forma de crear contenido de aprendizaje reutilizable dentro de un entorno de trabajo destinado al aprendizaje a travs de la Web [SCORM, 2004]. Es importante mencionar que para el desarrollo de la especificacin SCORM, ADL ha utilizado estndares de otras iniciativas. Al mismo tiempo, ha estado colaborando con dichas iniciativas en el desarrollo y mejora de dichos estndares. Algunas de estas iniciativas son:

Comit de Entrenamiento Basado en Ordenador de la Industria de la Aviacin o AICC.

Consorcio de Aprendizaje Global IMS o IMS GLC.

Instituto de Ingenieros Elctricos y Electrnicos o IEEE. Comit de Estndares en Tecnologas del Aprendizaje o LTSC.

38

La fundacin ARIADNE La ltima versin de ADL SCORM es la 2004, 4 edicin, esta, supuso un cambio sustancial sobre la versin 1.2 existente hasta ese momento. Algunos de los cambios ms significativos vienen dados por el entorno de ejecucin, la secuenciacin y navegacin de contenidos. En la tabla 2.1, se muestra la documentacin disponible para SCORM 2004, 4 edicin.

Tabla 2.1. Documentacin de SCORM 2004, 4Edicin.

Nombre del documento

Fecha

Documentation Suite Testing Requirements Version 1.1 Content Packaging Extensions XML XSD Version 2.0

14/08/2009 14/08/2009 31/03/2009

Sequencing Extensions XML XSD Version 2.0 Navigation Extensions XML XSD Version 1.0

31/03/2009 31/03/2009

A continuacin Nos centraremos en el modelo de datos, en el entorno de programacin y en la navegacin y secuenciacin de la especificacin SCORM. Modelo de Agregacin de datos Este documento es parte de la Documentation Suite y se encarga de: definir la terminologa utilizada en el modelo de contenidos SCORM, la descripcin y los requisitos para agregar y empaquetar contenido de aprendizaje, los metadatos para describir los elementos de SCORM y la descripcin y requisitos para definir la informacin de secuenciacin y navegacin.

39

Para entender el modelo de datos SCORM, es necesario conocer cada uno de los elementos de SCORM que construyen un recurso de aprendizaje.

Asset. Es el bloque bsico de construccin de un recurso de aprendizaje. Los assets son una representacin electrnica de un medio de comunicacin: texto, imgenes, sonidos o cualquier dato que pueda ser mostrado en un cliente Web (figura 18).

Asset Funciones JavaScript

Asset Pgina Web

Asset Documento XML

Asset Fragmento HTML

Asset Audio en MP3

Asset Audio en WAV

Asset Imagen JPEG

Asset Objeto Flash

Figura 18.

Assets [SCORM, 2004].

Es importante indicar que un asset puede ser construido por varios assets. Y que pueden describirse mediante metadatos. Facilitando la bsqueda y reutilizacin de estos.

Objeto reutilizable de aprendizaje o SCO. Es una coleccin de uno o ms assets y representa un recurso de aprendizaje ejecutable que utiliza el entorno de ejecucin SCORM para comunicarse con el sistema de gestin del aprendizaje o LMS. Un SCO debera ser independiente del contexto de aprendizaje donde es aplicado. De esta manera se facilitar su reutilizacin en otros contextos de aprendizaje. Al igual que los assets, el SCO ser descrito mediante metadatos.

40

Actividades. Una actividad puede ser descrita como una unidad de instruccin. Conceptualmente, es algo que el estudiante hace mientras progresa en su instruccin. Una actividad puede proporcionar al estudiante un SCO o asset. Tambin puede estar compuesta de otras actividades (figura 19).

Organizacin

Elemento o Item

Recurso

Actividades

Elemento o Item

Elemento o Item

Recurso

Elemento o Item

Recurso

Figura 19.

Actividades [SCORM, 2004].

Organizacin del aprendizaje o contenido. Es una representacin o mapa que define la utilizacin que se debe hacer dentro de la estructura de actividades o unidades de instruccin (figura 20).

Organizacin del Contenido Organizacin

Elemento o Item

Recurso

Elemento o Item Recurso

Elemento o Item Elemento o Item

Recurso

Figura 20.

Organizacin de Aprendizaje [SCORM, 2004].

41

La organizacin de aprendizaje puede ser descrita mediante metadatos. Es importante indicar que la secuenciacin solamente se aplica para actividades y series de actividades. La secuenciacin para un conjunto de actividades es definida como parte de una organizacin de aprendizaje.

Agregacin de contenido. Describe la accin o proceso para componer un conjunto de funcionalidades relacionadas con los objetos de aprendizaje o contenido, de tal forma que estos pueden ser aplicados en una experiencia de aprendizaje (figura 21).

Agregacin de Aprendizaje

Organizacin del Contenido

Organizacin

Elemento o Item

Recurso

Actividades

Elemento o Item Recurso

Elemento o Item Elemento o Item

Recurso

SCO Asset

Asset

Asset

SCO

Figura 21.

Agregacin de Aprendizaje [SCORM, 2004].

Una vez que el contenido de aprendizaje ha sido diseado y construido, es necesario que dicho contenido est disponible para: estudiantes, herramientas de autor,

42

repositorios de contenido, sistemas de gestin de aprendizaje (LMS). Para esta tarea, se cre el paquete de contenidos IMS, el cual, fue diseado para proporcionar una estructura estndar para el intercambio de contenidos. SCORM ha creado su propio paquete de contenido basndose en el paquete IMS, pero aadiendo informacin para poder empaquetar assests, objetos reutilizables de aprendizaje y organizacin de aprendizaje (figura 22).

Figura 22.

Ejemplo de SCO representado como un elemento <resource> [SCORM, 2004].

Entorno de Ejecucin SCORM Este documento describe los requisitos que el sistema de gestin de aprendizaje debe cumplir en la gestin del entorno de ejecucin: proceso para lanzar contenido, comunicacin entre contenido y sistema de gestin de aprendizaje (LMS), etc. Tambin se encarga de cubrir los requisitos del objeto reutilizable de aprendizaje (SCO) y el uso de la interfaz de programacin de aplicaciones (API). As como el modelo de datos del entorno de ejecucin SCORM (figura 23).

43

Sistema de Gestin del Aprendizaje

Servidor LMS

Lado del Servidor

de el lo de LM S y dato el s en SC tre O

Lanza
Navegador

Mo

Adaptador API
Comunicacin entre el SCO y el LMS

SCO JavaScript Asset

Lado del Cliente

Figura 23.

Entorno de ejecucin SCORM [SCORM, 2004].

Una vez que el LMS encuentra, a travs de la organizacin del aprendizaje, el objeto de aprendizaje dentro de la actividad, entonces es cuando el LMS lanza y presenta el SCO encontrado en el navegador del estudiante. Para establecer la comunicacin entre el SCO y el LMS se utiliza una API, basada en JavaScript, descrita por esta especificacin, (figuras 24 y 25). A continuacin se describirn alguna de las funciones ms importantes de la API.

Mtodos de sesin. El objeto de aprendizaje utiliza los mtodos de sesin para iniciar y terminar el intercambio de datos entre el mismo y el LMS. o Initialize(parametro) devuelve True o False. o Terminate(parmetro) devuelve True o False.

44

Figura 24.

API SCORM [SCORM, 2004].

Mtodos de transferencia de datos. El SCO utiliza estos mtodos para transferir datos de ejecucin hacia y desde el LMS. o GetValue(). El SCO pide informacin al LMS. o SetValue().El SCO manda informacin al LMS. o Commit(). Almacena los datos cacheados.

Mtodos de soporte. Son mtodos de la API que permiten a un SCO el manejo de errores e informacin de diagnostico. o GetLastError(). ltimo cdigo de error, producido en la instancia de la API. o GetErrorString(). Devuelve una descripcin del error que se ha producido.

45

o GetDiagnostic(). Solamente puede ser usada por el LMS. Permitiendo al LMS definir y aadir ms informacin de diagnostico.

Ejecucin
Initialize() Terminate() GetValue() SetValue() Commit() GetLastError() GetErrorString() GetDiagnostic() Terminate()

El SCO es lanzado por el LMS y ha encontrado la API

No inicializado
Initialize() GetLastError() GetErrorString() GetDiagnostic()

Terminado
GetLastError() GetErrorString() GetDiagnostic()

Figura 25.

Transicin de Estados de una instancia de la API de SCORM [SCORM, 2004].

El LMS debe soportar una instancia de la API. Esta Instancia, debe ser accesible va DOM, a travs de un objeto llamado API_1484_11. Adems, el LMS debe proporcionar al SCO acceso a la instancia de la API mediante ECMAScript. ECMAScript es un estndar de IEEE basado en JavaScript. Secuenciacin y Navegacin SCORM El documento de secuenciacin y navegacin de SCORM cubre las responsabilidades que el LMS adquiere a la hora de secuenciar objetos de aprendizaje durante el tiempo de ejecucin. Adems de permitir que los objetos indiquen peticiones de navegacin. Para realizar esto, ADL SCORM se basa en el estndar de secuenciacin de IMS (IMS-SS) [IMS-SS, 2003]. Para realizar esta tarea, SCORM utiliza la estructura de contenido que es una herramienta utilizada para describir la relacin jerrquica de una experiencia de aprendizaje (figura 26). IMS-SS describe esta estructura como rbol de actividad y permite a SCORM utilizarlo para describir requisitos de informacin y de procesamiento, como: algoritmos de secuenciacin y comportamientos.

46

Imsmanifest.xml rbol de Actividad

Organizacin

Datos de secuenciacin y seguimiento

Elemento o Item

Recurso

Elemento o Item Recurso

Elemento o Item Elemento o Item Elemento o Item

Recurso

Elemento o Item Elemento o Item

Recurso

Recurso

Figura 26.

rbol de actividad [SCORM, 2004].

2.5

Resumen

En este tema se ha descrito que es y para qu sirve una plataforma educativa. Estas plataformas educativas ofrecen un gran nmero de herramientas de administracin, colaboracin, evaluacin, etc., que facilitan el aprendizaje a travs de Internet. Otro aspecto clave en la utilizacin de las plataformas educativa es la utilizacin de estndares, estos estndares permiten la reutilizacin de contenido de aprendizaje y establecen mecanismos de comunicacin estndar que proporcionan caractersticas tan importantes como la reutilizacin de cursos, cuestiones, etc. Se ha aportado su descripcin formal y la visibilidad necesaria de los mismos para los desarrollos siguientes.

47

48

CAPTULO 3.

SISTEMAS DE GESTIN DEL APRENDIZAJE

3.1

Arquitectura General de un Sistema de Gestin del Aprendizaje

Se pude decir que un LMS es una aplicacin informtica que permite mostrar contenido educativo de una forma organizada y controlada. Actualmente, existen un gran nmero de LMS en el mercado. Estos pueden ser clasificados en:

LMS de iniciativa privada. Como el desarrollado por Microsoft y que recibe el nombre de Blackboard [Blackboard, 2009]. Este, se fusiono recientemente con otra plataforma privada llamada WebCT.

LMS de cdigo abierto. Son sistemas de aprendizaje que permiten modificar su estructura, aadir funcionalidades, etc., debido a que su cdigo est disponible para cualquier programador. Algunas de las iniciativas ms importantes son: DotLRN [DotLRN, 2009], Moodle [Moodle, 2009], Sakai [Sakai, 2009], Claroline [Claroline, 2009], etc. La arquitectura de un LMS (figura 27), est dividida en varios elementos: una base de datos, unos servicios (mdulos, bloques, paquetes, etc.) y un servidor Web.

Peticin

Usuario

Respuesta Servidor

Base de Datos

Plantillas

Servicios

Figura 27.

Arquitectura bsica de un sistema de gestin de aprendizaje.

49

Base de datos del LMS. Almacena informacin como usuarios, roles, cursos, etc. Esta informacin ser utilizada por los servicios del LMS y mostrada al usuario, mediante plantillas. Algunos de los sistemas de gestin de base de datos utilizados son: Oracle, PostgreSQL, Mysql, etc.

Mdulos, bloques, paquetes, etc. La estructura de los paquetes o mdulos y el lenguaje de programacin utilizado depende del LMS. Cada mdulo o paquete soporta la lgica de un servicio o de parte de ste. Por ejemplo, en Moodle el lenguaje de programacin utilizado sera PHP [PHP, 2009] [Curioso, 2007] y el mdulo chat, como su propio nombre indica gestiona los chats creados, las conversaciones, etc. Todo ello, utilizando la informacin de la base de datos. Es importante indicar que los paquetes o mdulos pueden ser aplicaciones o servicios (figura 28): o Aplicaciones. Son utilidades usadas directamente por el estudiante o profesor. Por ejemplo, foros, chats, etc.

Aplicaciones
Foros Documentos Correo
(bulk mail)

FAQs

Notificaciones

Servicio Correo
(ACS-mail-lite)

Sistema de plantillas

Webdav

Servicios

Figura 28.

Relacin entre Aplicaciones y Servicios.

50

Servicios. Ofrecen funcionalidades a las capas superiores (aplicaciones, etc.) o a otros mdulos o paquetes. Por ejemplo, servicio de notificaciones, servicio de correo, etc.

Servidor Web. Todos los LMS son instalados junto con un servidor web. Este permite mostrar la informacin al usuario a travs de peticiones HTTP. Al igual que los elementos anteriores, el servidor web utilizado depender del LMS. As, Moodle tiene instalado Apache. Este captulo se basar principalmente en los LMS de software libre. Al tener su cdigo publicado, permiten que cualquier persona pueda conocer su arquitectura interna y modificarla segn las necesidades de su organizacin. A continuacin se describirn algunos de los LMS de cdigo abierto ms utilizados.

3.2

.LRN

.LRN o dotLRN es una plataforma de software libre para comunidades de aprendizaje e investigacin, que dispone de capacidades de: gestin de cursos, comunidades virtuales, gestin de contenidos y del aprendizaje. Inicialmente fue desarrollada por el Instituto Tecnolgico de Massachusetts como parte del Intellectual Commons, Actualmente .LRN est respaldado por un consorcio mundial de instituciones educativas, organizaciones sin nimo de lucro, empresas y desarrolladores de cdigo abierto. Es importante mencionar que .LRN es un paquete de OpenACS enfocado al entorno educativo. Por tanto, antes de continuar hablando de .LRN, ser necesario describir que es OpenACS y para qu sirve. OpenACS es una herramienta avanzada para la construccin de aplicaciones Web orientadas a comunidades [OpenACS, 2009]. Es decir, es una coleccin de aplicaciones y servicios que se pueden utilizar para crear aplicaciones y sitios Web de

51

forma modular. Algunos de estos mdulos (en terminologa de OpenACS se denominan paquetes) permiten: gestin de usuarios y grupos, gestin de contenidos, comercio electrnico, noticias, preguntas ms frecuentes o FAQs, calendarios, foros, bsqueda de texto, gestin de actividades educativas (.LRN), etc. OpenACS utiliza el servidor Web AOLserver [AOLserver, 2009]. Este es un servidor de aplicaciones Web: libre, multihilo, escalable y que soporta TCL como lenguaje de programacin [TCL, 2009]. Adems de todo esto, OpenACS permite trabajar con varios gestores de bases de datos, entre ellos: Oracle y PostgreSQL. Una vez que se ha indicado que .LRN es una aplicacin que se instala sobre OpenACS y que se utiliza para la gestin de comunidades virtuales de aprendizaje e investigacin, se mencionarn algunos de las aplicaciones y servicios ms destacados, as como algunas de sus caractersticas ms significativas (figura 29) [dotLRN, 2009].

Cuestionarios Correo electrnico Calendario

Foros LORS Gestin de LORS Noticias lbum de fotos

Comercio electrnico .LRN Tareas Editar pgina Evaluacin Seguimiento de gastos

Gestin de proyecto Lista de miembros Encuestas

Seguimiento de usuarios Blog

Almacn de documentos

Presentaciones

Figura 29.

Aplicaciones .LRN [dotLRN, 2009].

52

Creacin y gestin de comunidades. Permite crear comunidades de aprendizaje, incluyendo otras aplicaciones como calendarios, almacenes de ficheros, etc.

Gestin de repositorios de contenido. Esta aplicacin gestiona los servicios de un repositorio de objetos de contenido: cargar cursos, gestionar y crear metadatos, borrar recursos y cursos. dotLRN soporta estndares de contenido como IMS-CP y SCORM v1.2 (Actualmente no soporta SCORM 2004).

Cuestionarios. Este paquete permite realizar encuestas, pruebas de evaluacin y recopilar informacin de forma dinmica. Las caractersticas que ofrece este mdulo son: o Crear evaluaciones que permitan respuestas annimas. o Crear diferentes tipos de evaluaciones como: exmenes, repasos de conceptos, encuestas, etc. o Establecer la duracin de la evaluacin y el nmero de intentos permitidos. o Reutilizar secciones y preguntas. o Crear diferentes tipos de preguntas: preguntas abiertas, de mltiple eleccin, preguntas que permitan cargar ficheros con la respuesta, etc. o Importar ficheros QTI para crear evaluaciones o exportar evaluaciones a ficheros QTI. Es decir, soporta el estndar IMS-QTI.

Seguimiento de usuarios. Estadsticas completas de visitas de los usuarios a los diferentes mdulos o paquetes dentro del LMS.

53

Calendario. Los profesores puede enviar eventos al calendario del curso en el que estn. Los administradores puede enviar eventos al calendario de la comunidad. A parte de estos dos calendarios el estudiante tiene su propio calendario, donde puede incluir recordatorios, como entrega de trabajos o reuniones con otros compaeros.

Tareas o Homework. Este paquete crea un rea que permite a un estudiante cargar un fichero o ficheros con trabajos que han sido solicitados por el profesor. El profesor podr comentar y evaluar dichos trabajos. Estos comentarios y evaluaciones sern mostrados al estudiante que realizo los trabajos.

Documentos. Todos los usuarios tienen acceso a un almacn de archivos personales donde pueden cargar los archivos privados o archivos pblicos que se comparten con otros usuarios registrados. Los profesores, tutores y administradores de grupo pueden subir archivos en el almacn de la clase/comunidad para su distribucin a los estudiantes o miembros de la comunidad.

Blogs. Permite que los estudiantes tengan blogs personales, as como blogs para las clases, grupos y comunidades. Por tanto, estos blogs pueden ser utilizados por un individuo o por un grupo de individuos. Esta funcionalidad incluye un soporte completo para RSS y la entrada de texto con formato.

Wiki. Est basado en un editor de texto, combina aspectos de wikis (colaboracin entre profesores y estudiantes, facilidad de creacin de pginas, etc.), con aspectos de un sistema de administracin de contenido (revisiones, reutilizacin de recursos, mltiples lenguajes). Permite a los usuarios hacer

54

comentarios en las pginas, etiquetar al estilo del.icio.us y, estructurar la informacin de las pginas. Utiliza la sintaxis de MediaWiki. Estas herramientas, blogs, RSS, Wikis, etc., son muy importante en el marco de la Web 2.0. Esta no es una tecnologa ni un conjunto de tecnologas sino uno idea de utilizar la Internet y la Web para: 1. Facilitar la mxima interaccin entre los usuarios y el desarrollo de redes sociales (tecnologas sociales). Donde estos usuarios puedan expresarse, opinar, buscar y recibir informacin de inters, colaborar y crear conocimiento (conocimiento social) 2. Compartir contenidos, etc.

Foros. Incluye un soporte altamente configurable para foros de discusin. Los foros pueden ser planos o multi-hilos, moderados o no moderados, abiertos, cerrados; o pueden ser configurados de manera que solamente el administrador pueda crear nuevos tpicos de discusin. Los mensajes pueden ser slo texto o HTML y pueden incluir URLs y archivos adjuntos. Cuenta con un sistema de notificaciones va email fcilmente configurables, permitiendo responder a travs de tu propio cliente de correo electrnico.

Noticias. Proporciona un mecanismo de comunicacin de una va para enviar noticias o anuncios a los miembros de un grupo o de una comunidad.

Chats. Habilita la posibilidad de interaccin con usuarios conectados dentro del sistema con la posibilidad de utilizar dos interfaces (HTML o Ajax).

Lista de miembros. Lista de personas participantes en cursos y sus roles e informacin de contacto.

FAQs. rea de preguntas ms frecuentes.

55

Internacionalizacin. Permite soportar mltiples idiomas.

Por ltimo, conviene hacer mencin aparte, de uno de los servicios ms importantes de un LMS que es la autenticacin de los usuarios en el sistema. dotLRN proporciona una base de datos interna que respalda la infraestructura de autenticacin. Tambin da soporte a mecanismos de autenticacin externa como: Kerberos [Kerberos, 2009] o LDAP.

3.2.1

Desarrollo de Aplicaciones o Paquetes

Como se ha indicado anteriormente, dotLRN es una aplicacin para la gestin de comunidades virtuales de aprendizaje e investigacin basado en OpenACS. Al ser software libre, permite conocer la arquitectura y programacin de todos y cada uno de sus componentes. As, la arquitectura de dotLRN (figura 30) se asemeja a la arquitectura general, vista anteriormente, de un LMS, donde hay un sistema de gestin de base de datos (que mantiene la informacin utilizada por el sistema de gestin del aprendizaje), un servidor web, que recibe/enva informacin desde o hacia el usuario, y servicios y aplicaciones, que en algunos casos soportan estndares e-learning. As, dotLRN permite:

Utilizar los servicios y aplicaciones que ofrece.

Modificar los servicios y aplicaciones que ofrece.

Crear nuevas aplicaciones y servicios. Para desarrollar estas dos ltimas opciones es necesario conocer muy bien el modelo de datos que utiliza dotLRN, su sistema de ficheros, los ficheros que utiliza, etc. As, cuando se instala OpenACS y dotLRN se puede apreciar la siguiente estructura de directorios (figura 31):

56

Modulo de Aplicaciones
Administracin de Cursos (Calendario, Evaluacin, Seguimiento de usuarios) Standards (IMS, SCORM) Collaboration (forums, chats) Contenidos (gestin de contenidos, rea de almacenamiento, etc.) Otros (e-commerce)

Servicios de Aplicaciones
(Repositorio de contenidos, Servicios Web, etc.)

Servicios de la plataforma
Desarrollo de software (gestin de paquetes, plantillas, etc.) Orientacin a Objetos Seguridad (Permisos OpenACS, restricciones de pgina, etc)

AOLserver (TCL) Base de datos (PostgreSQL, Oracle)

Sistemas operativos (Windows, Solaris, Linux,BSD)

Figura 30.

Arquitectura dotLRN [dotLRN, 2009].

Figura 31.

Sistema de ficheros dotLRN.

Directorio bin. Contiene varios ejecutables y scripts para el mantenimiento del servidor.

Directorio

content-repository-content-file.

Contiene

los

contenidos

del

repositorio de contenidos almacenados en el sistema.

Directorio etc. Contiene los scripts de instalacin y ficheros de configuracin

57

Directorio packages. Contiene los directorios donde se almacena los servicios y aplicaciones de dotLRN.

Directorio log. Contiene los logs de acceso y de errores del servidor.

Directorio tcl. Contiene informacin y llamadas para iniciar el servidor web OpenACS.

Directorio www. Contiene las pginas que no estn incluidas en los paquetes (contenido esttico, pginas personalizadas) Por tanto, se puede decir que los paquetes de dotLRN estn almacenados en subdirectorios que se encuentran dentro del directorio packages. Cada una de estas subdirectorios, tienen una estructura comn que encapsula el modelo de datos, las libreras, la lgica de programacin, las pginas de administracin y las pginas de usuario de un paquete. En la figura 32 se puede ver la arquitectura general de un paquete y una breve descripcin de las carpetas y ficheros que lo forman. Es importante indicar que dotLRN utiliza un conjunto de ficheros, con las siguientes extensiones:

El lenguaje de programacin utilizado en dotLRN es TCL, por tanto los ficheros que contienen la lgica de los servicios y aplicaciones tendr la extensin .tcl.

La manera ms sencilla de crear pginas dinmicas con AOLserver es incorporar cdigo TCL dentro de las pginas HTML para crear AOLserver Dynamic Pages (ADPs). Estos ficheros tienen la extensin .adp. Ficheros con extensin .sql que permiten la creacin de modelos de datos. Segn la instalacin que se haya hecho para dotLRN, estos ficheros sern para Oracle o para Postgresql.

58

Ficheros con extensin .xql son utilizados por algunos ficheros TCL para hacer consultas en el modelo de datos (son fichero xml que incrustan SQL). Los ficheros con extensin xql deben tener el mismo nombre que el fichero TCL que lo utiliza. Se acaba de ver la estructura del sistema de ficheros de dotLRN y la estructura que tiene un paquete. Para finalizar con este apartado, conviene indicar otros aspectos claves para desarrollar un paquete: 1. Es conveniente conocer el modelo de datos que dotLRN nos ofrece, y ver como relacionar ese modelo con el paquete que se va a desarrollar. 2. Antes de desarrollar un paquete es necesario conocer el funcionamiento de los servicios y aplicaciones que nuestro paquete necesita. De tal forma, que se puedan hacer llamadas a su API correspondiente (reutilizar cdigo) 3. Es posible diferenciar tres tipos de paquetes: paquete normal (chat), paquete Portlet (chat-portlet) y paquete Applet (dotlrn-chat), estos pueden convivir y dar lugar a una nica aplicacin (figura 33). As: a. Paquete normal (chat). Contiene tanto el modelo de datos, como la lgica y funcionamiento del paquete. As como la interfaz de usuario del paquete. b. Paquete Portlet (chat-portlet). Proporciona la interfaz de usuario para los portales. c. Paquete Applet (dotlrn-chat). Utiliza la interfaz de los portlets y establece las propiedades para el portal de dotLRN.

59

root packages Nombre del paquete Nombre del paquete.info sql oracle Nombre del paquete-create.sql Nombre del paquete-drop.sql *.sql updates Script de creacin del modelo de datos del paquete para Oracle Script de borrado del modelo de datos del paquete para Oracle Ficheros del modelo de datos Contiene los ficheros para actualizar el modelo de datos (nuevas versiones) Tiene la misma estructura que el directorio Oracle. Pero para Postgresql Modelo de datos del paquete Fichero de especificacin del paquete en XML donde se indica el nombre, propietario, url, etc.

postgresql

tcl

Contiene la lgica del paquete *-oracle.xql *-postgresql.xql Ficheros con consultas especficas de Oracle. El nombre del fichero, debe coincidir con el nombre del fichero TCL que utiliza dichas consultas Ficheros con consultas especficas de Postgresql. El nombre del fichero, debe coincidir con el nombre del fichero TCL que utiliza dichas consultas Proporciona una API para el paquete Proporciona los procedimientos TCL que se ejecutarn una nica vez al iniciar el servidor

Nombre del paquete-procs.tcl Nombre del paquete-init.tcl lib www admin doc resources

Contiene ficheros TCL y ADP que pueden ser incluidos en otros ficheros Interfaz de usuario, documentacin, pruebas para el comprobar el funcionamiento del paquete, etc. Contiene una serie de ficheros y directorios para crear la interfaz de usuario y probar que el paquete funciona correctamente. Documentacin del paquete Ficheros de contenido esttico Para la creacin del interfaz de usuario

Ficheros tcl, adp, xql Otros paquetes

Figura 32.

Estructura de un paquete de OpenACS y dotLRN [OpenACS, 2009].

60

Figura 33.

Paquetes, portlets y applets [Pesquera, 2009].

3.2.2

aLF

En ocasiones, instituciones y universidades necesitan adaptar dotLRN a sus necesidades: Creando nuevas estructuras para los portales, modificando servicios o aplicaciones ya existentes o creando nuevos servicios y aplicaciones. Un ejemplo de esto, es la plataforma aLF. Dicha plataforma es utilizada por la Universidad Nacional de Educacin a Distancia (UNED) para impartir sus cursos a distancia [CINDETEC, 2009].

61

Antes de comenzar con la descripcin de aLF. Se va a definir, de nuevo, el concepto de portal de Internet. As, mientras que un sitio Web es un conjunto de pginas Web, en un mismo dominio, que comparte un mismo objetivo y temtica. Un portal de Internet es un sitio Web que ofrece varios servicios y/o utilidades de forma conjunta a muchos usuarios. Estos usuarios tienen una cuenta de acceso al portal. Por ltimo indicar, que la forma de mostrar cada una de estas aplicaciones en una pgina web es dentro de Portlets. aLF por tanto es una adaptacin y modificacin de dotLRN a las necesidades de la Universidad Nacional de Educacin a Distancia (UNED). A continuacin, se describir la interfaz de usuario y posteriormente algunos de los servicios modificados y creados por la Seccin de Innovacin del Centro de Innovacin y Desarrollo Tecnolgico de la UNED (INNOVA). Interfaz de Usuario aLF organiza los elementos de cada pgina en las siguientes reas (figura 34):

Cabecera. Siempre estar disponible y mostrar: el logo de la UNED, ttulo de la pgina, nombre del usuario, una barra con opciones generales (ayuda, cambiar idioma, panel de control, accesibilidad, salir), la barra de migas de pan, las pestaas de contexto (inicio, cursos y comunidades).

Panel lateral. Se puede mostrar u ocultar, de tal forma que podamos utilizar esa rea para mostrar los contenidos. Normalmente esta rea depende del rol de usuario. As si un administrador tendr: una seccin de enlaces para navegar por las herramientas del grupo, una seccin de administracin con enlaces de administracin y un mini calendario en los que se muestran los eventos de ese mes.

62

Contenidos. Es el rea de trabajo y donde se encuentran los portlets En la figura 35 se pueden ver los portlets mostrados en un curso.

Pe de pgina. Muestra la pgina principal de la institucin, y la poltica de privacidad.

Cabecera

Contenidos

Panel Lateral

Pie de Pgina

Figura 34.

Interfaz de usuario de aLF.

Figura 35.

rea de contenidos con los portlets noticias, chat, grupos

63

Servicios ofrecidos por aLF aLF ofrece muchos de los servicios y herramientas de los que dispone dotLRN como: blogs, chat, foros, calendarios, creacin de grupos, etc. Pero tambin, como se ha comentado es posible modificar y crear nuevos servicios dentro de dotLRN. As, aLF:

Ha adaptado el servicio de autenticacin con el basado en el LDAP de la UNED. De tal forma que el estudiante al autenticarse en el portal de la UNED, pueda acceder de forma transparente a las comunidades de aLF a las que pertenece.

Aade el servicio de recordatorios en la herramienta calendario. De tal forma que al estudiante, profesor, administrador, etc., se le notifique los eventos que van a tener lugar y que son de su inters.

Ha Mejorado los foros ofrecidos por dotLRN, etc.

Ha incorporado nuevos servicios para crear los grupos Facultades y Departamentos.

Ha incorporado nuevos servicios para crear los grupos de grados para el nuevo plan Bolonia. Uno de los temas de esta tesis se basa en estos dos ltimos puntos para permitir crear grupos de laboratorios virtuales y remotos, y aadirles servicios tales como: Chat, Wikis, blogs, etc.

3.3

Moodle

Moodle es un paquete de software libre para la creacin de cursos y sitios Web basados en Internet. Este software esta desarrollado en PHP, normalmente, como

64

base de datos utiliza MySQL, aunque tambin puede utilizar PostgreSQL y Oracle y el servidor web que utiliza es Apache.

3.3.1

Servicios y Aplicaciones ofrecidas por Moodle

Moodle es un software modular. Estos mdulos se pueden clasificar en tres grupos [Moodle, 2009] [William, 2008] [Bchner, 2008] (figura 36):

Mdulos de actividad. Pueden incluirse en el curso, algunas de esta actividades son: o Chat. Permite que los participantes mantengan una conversacin en tiempo real (sncrono) a travs de Internet. o Foros. Pueden estructurarse de diferentes maneras, y cada mensaje puede ser evaluado por los compaeros. Los mensajes tambin se pueden ver de varias maneras, incluir mensajes adjuntos e imgenes incrustadas. Al suscribirse a un foro los participantes recibirn copias de cada mensaje en su buzn personal de correo electrnico. El profesor puede forzar la suscripcin a todos los integrantes del curso si as lo desea. o Glosarios. Esta actividad permite a los participantes crear y mantener una lista de definiciones, como un diccionario. o SCORM. Permite cargar fcilmente cualquier paquete SCORM estndar y convertirlo en parte de un curso. o Blogs. permite tener un diario personal pblico, en formato Web, a los estudiantes, profesores y administradores.

65

o Wiki. Permite a los participantes trabajar juntos en pginas web para aadir, expandir o modificar su contenido. Las versiones antiguas nunca se eliminan y pueden restaurarse. Al igual que en .LRN, blogs, wikis, etc., facilitan el desarrollo de la web 2.0. o Sistema de Control de Actividades de Aprendizaje LAMS. Se utiliza para disear, manejar y desarrollar actividades de aprendizaje online en colaboracin. Se efecta por medio de un entorno visual para crear secuencias de actividades de aprendizaje. Estas actividades pueden incluir un rango de tareas individuales, pequeo grupo de trabajo y actividades de todos los estudiantes basadas en ambos conceptos: contenido y colaboracin. Est relacionado con el estndar IMS-LD. o Taller. Es una actividad para el trabajo en grupo con un vasto nmero de opciones. Permite a los participantes diversas formas de evaluar los proyectos de los dems, as como proyectos-prototipo. Tambin coordina la recopilacin y distribucin de esas. o Mdulos no estndar. Son mdulos creados por desarrolladores y que pueden ser utilizados por organizaciones que los encuentren de utilidad.

Recursos. Moodle ofrece un conjunto de diferentes recursos que nos permiten aadir cualquier contenido en nuestro curso: o Una pgina de texto. Es una pgina escrita en texto sin formato. Las pginas del texto no son bonitas, pero pueden servir para poner alguna informacin. o Una pgina Web. Si desea aadir ms informacin que texto.

66

Actividad

Recurso

Bloques

Figura 36.

Actividades, Recursos y Bloques Moodle [Moodle, 2009].

o Enlazar un archivo o una Web. En el caso de que el recurso exista previamente en formato electrnico puede desear mostrar dicho contenido en su curso. o Paquete IMS puede aadirlo al curso (relacin con IMS-CP). o Una etiqueta. Se utiliza para incluir instrucciones o informacin en alguna seccin del curso.

Bloques. Proporcionan informacin o funcionalidad adicional al estudiante o al profesor. Estos aparecen en los laterales de las pginas de Moodle y pueden agregarse, borrarse, desplazarse lateralmente y/o verticalmente, etc. Dos claros ejemplos de bloques son los calendarios o el bloque de administracin para profesores y administradores de un curso. Existen bloques que se instalan por defecto, mientras que hay otros bloques no estndares que tiene que ser instalados por el administrador de Moodle, algunos de estos son: usuarios en lnea, novedades, canales RSS remotos, etc.

67

Como en el apartado anterior, es importante mencionar el servicio de autenticacin. Moodle, al igual que dotLRN, proporciona una base de datos interna que respalda la infraestructura de autenticacin. Tambin da soporte a mecanismos de autenticacin externa como: Kerberos [Kerberos, 2009] o LDAP.

3.3.2

Desarrollo de Mdulos y Bloques

Moodle ofrece la posibilidad de crear o modificar mdulos y bloques nuevos o ya existentes. A continuacin, se describirn algunos de los ficheros y carpetas ms importantes del directorio Moodle (figura 37), para posteriormente centrarnos en la creacin de bloques y mdulos. Es importante mencionar, que cuando se instala Moodle, se crea una carpeta con ese mismo nombre en el directorio htdocs de apache. Este directorio contendr un conjunto de ficheros y directorios encargados de crear y gestionar los servicios de Moodle. A continuacin describiremos algunos de estos directorios y ficheros: config.php. Es el fichero de configuracin de Moodle. install.php. Contiene el script que se ejecutar para crear el archivo config.php. index.php. Es la pgina principal del sitio. admin/. Contiene los ficheros php para administrar Moodle. auth/. Contiene los mdulos para la autenticacin de usuarios (ldap, shibboleth, etc.). blocks/. Contiene los bloques que son contenidos en los laterales de las pginas de Moodle.

68

Figura 37.

Estructura del directorio Moodle.

version.php. Contiene informacin sobre la versin de Moodle utilizada. calendar/. Contiene el cdigo para manejar y mostrar eventos de calendario. course/. Contiene el cdigo para presentar y gestionar los cursos. doc/. Contiene la documentacin de ayuda de Moodle.

files/ - Cdigo para presentar y gestionar los archivos cargados. lang/. Contiene los mdulos para el idioma o idiomas soportados. lib/. Contiene las libreras para Moodle. mod/. Contiene todos los mdulos de los cursos de Moodle. user/. Contiene el cdigo para mostrar y gestionar los usuarios. Aunque para crear o modificar, tanto mdulos, como bloques, es necesario conocer ms en profundidad las variables de entorno, APIs de los mdulos, Modelo de datos,

69

etc. En este apartado nos centraremos en cmo crear mdulos o bloques de forma sencilla y rpida. Bloques Los Bloques, se pueden colocar en las columnas laterales y son elementos "de apoyo" al proceso de enseanza-aprendizaje. Algunos ejemplos son: bloque de buscador de foros, bloque de mensajera, bloque de administracin, etc. Normalmente, cada uno de los bloques instalados en Moodle, se encuentran en una carpeta dentro del directorio blocks/ de Moodle. Para definir un bloque de Moodle, en el caso ms bsico, solamente es necesario crear un archivo de cdigo fuente. A continuacin se describir paso a paso la creacin de este tipo de bloques: 1. Crear un directorio con el nombre del mdulo que se va a desarrollar (/blocks/nombrebloque/) 2. Crear un fichero vacio con extensin php dentro del directorio creado (/blocks/nombrebloque/block_nombrebloque) 3. Editar el fichero para que contenga la lgica del bloque. Este fichero debe seguir la estructura indicada en la figura 38 [Moodle, 2009]. En la figura 38, se indica que el bloque creado hereda de una clase base llamada block_base. Por tanto el programador podra usar, e incluso, modificar los mtodos y variables de dicha clase, algunos de estos son: o Mtodos que se puede utilizar y sobrescribir libremente. applicable_formats. Permite controlar a que formatos puede ser agregado tu bloque.

70

config_print. Permite escoger como mostrar la pantalla de configuracin global para el bloque. Esta es la pantalla que se le presenta al administrador cuando escoge "Configuracin..." para un bloque especfico.

class block_nombrebloque extends block_base {

Define la clase Bloque, que hereda de una clase base, llamada block_base

// Declaracin de variables

function init() { $this->title = get_string('nombrebloque', 'block_nombrebloque'); $this->version = 2009121200; // Otras variable }

Mtodo init, es esencial para todos los bloques y su propsito es definir las variables a utilizar en el bloque, como: - This->title (ttulo que aparecer en la cabecera del bloque) - This->version (versin YYYYMMDD00)

function get_content() { global $CFG; if ($this->content !== NULL) { return $this->content; } // Cdigo que gestiona y muestra el contenido del bloque } Muestra el contenido del bloque

function instance_allow_config() { return true; }

Permite a los profesores configurar lo que hay en el bloque. Esto es lo que se denomina Configuracin de Instancias Si est funcin se incluye, es necesario crear un archivo config_instance.html dentro de la carpeta /blocks/nombrebloque/

// otros mtodos ya definidos o creados por el usuario }

Figura 38.

Estructura del Fichero de un bloque Moodle.

config_save.

permite

sobrescribir

el

mecanismo

de

almacenamiento de los datos de configuracin. get_content. Como se ha visto en la figura 35 permite mostrar el contenido del bloque. Init. Como se ha visto en la figura 35, este mtodo debe ser implementado para todos los bloques. Tiene que asignarles

71

valores significativos a las variables de objeto $this->title, y $this->version. has_config. Debe retornar un valor booleano, que indique si el bloque quiere presentar una interfaz de configuracin al administrador del sitio o no. hide_header. Debe retornar un valor booleano, que indique si nuestro bloque quiere esconder su cabecera (o ttulo). html_attributes. Debe retornar un array de atributos HTML que le sern entregados al elemento contenedor de tu bloque cuando Moodle construya la salida HTML. instance_allow_config. Debe retornar un valor booleano. True, indica que tu bloque quiere tener una configuracin por instancia, mientras false significa que no. instance_allow_multiple. Debe retornar un valor booleano, indicando si quieres permitir mltiples instancias de este bloque en una misma pgina o no. instance_config_print. Permite seleccionar como mostrar la pantalla de configuracin de instancia para tu bloque. instance_config_save. Permite sobrescribir el mtodo de almacenamiento para los datos de configuracin de tu instancia. preferred_width. Debe retornar un valor entero, el cul es el nmero de pxeles de ancho que tu bloque quiere tomar cuando sea mostrado.

72

refresh_content. debe hacer que tu bloque recalcule su contenido inmediatamente. El programador debe retornar el nuevo valor de $this->content despus de refrescarlo.

Specialization. Este mtodo es llamado inmediatamente despus de que los datos de instancia (tipo de pgina, id y todos los datos de configuracin de la instancia) son cargados de la base de datos.

o Mtodos que se puede utilizar, pero no sobrescribir. instance_config_commit. guarda el contenido actual de la variable de objeto $this->config en la base de datos. get_content_type. Este mtodo retorna el valor de la variable de objeto $this->content_type. Tambin es la manera ms

adecuada de acceder a dicha variable. get_title. Retorna el valor de $this->title. Tambin es la manera ms adecuada de acceder a dicha variable. get_version. Retorna el valor de $this->versin. Tambin es la manera ms adecuada de acceder a dicha variable. is_empty. Retorna un valor booleano, verdadero/falso,

dependiendo de si el bloque tiene contenido para mostrar o no. Name. Retorna el nombre interno del bloque dentro de Moodle, sin el prefijo block_. o Variables y constantes de la clase.

73

$this->config.

Esta

variable

guarda todos los

datos

de

configuracin que han sido dados a una instancia de la clase. $this->content_type. Esta variable le indica a Moodle el tipo de contenido del bloque. Los nicos valores vlidos para esta variable son las dos constantes llamadas BLOCK_TYPE_TEXT y BLOCK_TYPE_LIST. $this->content. Esta variable guarda el contenido que se muestra dentro de cada bloque. Dependiendo del tipo de bloque (texto o lista) se guardarn datos distintos. $this->instance. Esta variable guarda toda la informacin especfica que diferencia una instancia de bloque $this->title. Esta variable es un string que contiene el nombre del bloque. $this->versin. Esta variable debe guardar el nmero de la versin del bloque en la forma YYYYMMDDXX, por convencin a travs de Moodle. o Constantes de la clase: BLOCK_TYPE_TEXT y BLOCK_TYPE_LIST. Una vez realizados estos tres paso tenemos creado un bloque de Moodle, ahora solamente quedara que el administrador instale dicho bloque. Mdulos de Actividades Un Mdulo Moodle puede dividirse en dos grandes categoras: Los recursos y las actividades.

74

Los Recursos. son ms bien para cuestiones de auto-estudio, y "priorizan" la interaccin persona-contenido (procesos de aprendizaje "pasivos").

Las Actividades son de tipo colaborativo, y "priorizan" la interaccin persona(s)persona(s) (de uno a uno y de varios a varios; procesos de aprendizaje "activos"). Este apartado, se centrar en la creacin de un mdulo de actividad. Estos mdulos, suelen estar en subcarpetas dentro de la carpeta moodle/mod/ y tiene como nombre de la carpeta el mismo nombre que el mdulo (figura 39). Cada mdulo debe seguir una estructura de ficheros y directorios, en la figura 37 se muestra dicha estructura y una breve descripcin de cada uno de sus elementos.

Figura 39.

Carpeta /mod y mdulos de Actividad.

Cuando se desarrolla una actividad, a parte de esta estructura (figura 40), es conveniente tener en cuenta tres aspectos muy importantes: 1. El nombre del mdulo no debe contener nmeros, ni caracteres especiales.

75

2. Es necesario crear una tabla con el mismo nombre que tiene el mdulo. Adems de esto, la tabla deber contener como mnimo tres campos: id, curso, nombre. 3. Debe asegurarse de que su mdulo proporciona soporte para grupos y metacursos.

moodle mod nombremodulo db install.xml upgrade.php access.php esquema de la base de datos en xmldb. Este fichero se utiliza cuando se instala el modulo en Moodle. Define los cambios en el esquema de la base de datos. Se ejecuta cuando se actualiza el mdulo Contiene las capacidades (permisos del mdulo) Mdulo que vamos a crear

icon.gif version.php index.php lib.php view.php mod_form.php backuplib.php restorelib.php settings.php o settingstree.php lang otros ficheros.php otros

Icono grfico que se asocia al mdulo Contiene informacin sobre la versin del mdulo Muestra la lista de instancias de actividades del mdulo que hay en el curso. Funciones requeridas por Moodle para comunicarse con este mdulo. Muestra una instancia particular de la actividad Formulario para configurar o actualizar una instancia de esta actividad Funciones para realizar las copias de seguridad del mdulo Funciones para restablecer una copia de seguridad del mdulo Pgina de administrador del mdulo (opcional)

Contiene los ficheros de idiomas para esa actividad Otros ficheros especficos de este mdulo y creados por el programador Otros directorios creados por el programador del mdulo

Otros mdulos

Figura 40.

Estructura de una actividad de Moodle.

Una vez creado el mdulo, cualquier administrador de Moodle, podr cargar su mdulo y dejarlo funcionando para cualquier profesor que lo necesite.

76

3.4

Sakai

Sakai es un entorno de aprendizaje colaborativo (CLE) basado en web, y de cdigo abierto [Berg, 2009], que permite a los profesores crear cursos y aadir chats, foros, blogs, wikis, y muchas otras herramientas. Los estudiantes, pueden, entre otras cosas, cargar sus tareas, usar las herramientas aadidas por el profesor (foros, wikis, etc.) e interactuar con los compaeros de clase o con el profesor. Los investigadores y grupos de investigadores pueden crear sitios para compartir material e interaccionar unos con otros. Es importante mencionar que Sakai dispone de un conjunto de entornos de trabajo (estructuras internas) que facilitan la creacin de herramientas. Una vez definido que es Sakai, se va a describir brevemente su arquitectura, para posteriormente centrarse un poco ms en los servicios que ofrece. Al igual que la mayora de los LMS, la arquitectura de Sakai, est formada por: una base de datos, un conjunto de herramientas y servicios, y un servidor Web.

Base de datos. Sakai necesita mantener los datos persistentes en una base de datos. Actualmente las bases de datos soportadas por Sakai son: MySQL y Oracle. En ocasiones, se almacena contenido en el sistema de ficheros.

Servicios y herramientas. Sakai es un conjunto de aplicaciones Web ejecutndose en un contendor Servlet con algunos servicios centrales compartidos. o Las herramientas. Son unidades que realizan una funcionalidad concreta como un wiki o una herramienta de bsqueda de contenido. o Los servicios. Son utilizados por las herramientas y los encargado de la lgica y detalles de implementacin, como que tipo de base de datos se est utilizando o que est haciendo el sistema de ficheros.

77

Servidor Web. Se ha comentado que Sakai est en un contenedor servlet, por tanto es necesario ejecutarlo en un servidor que soporte java y que permita recibir peticiones y enviar respuestas a travs de la web. Por todo ello, Sakai utiliza el servidor Tomcat. En ocasiones, Sakai puede ejecutarse sobre JBoss, aunque hay muy pocas instalaciones con l. Como en el restos de sistemas de gestin de aprendizaje, Sakai, ofrece un conjunto de herramientas y servicios por defecto y permite que otras organizaciones diseen y desarrollen sus propias herramientas para Sakai (figura 41). A continuacin se vern algunos ejemplos de herramientas utilizadas al crear un curso. o Recursos o sistema de almacenamiento. El estudiante, profesor o investigador puede subir ficheros a dicha rea. o Anuncios. Crea un sitio especfico para anuncios. Dentro del sitio se pueden definir grupos y miembros, permitiendo un mejor flujo de la informacin.

Tareas

Figura 41.

Curso Sakai.

o Blogs. permite tener un diario personal pblico, en formato Web.

78

o Salas de chat. Permiten crear reas para la comunicacin sncrona entre estudiantes o entre estudiante-profesor. o Noticias. Permite publicar noticias, mediante RSS, obtenidas de otros sitios y fuentes. o Calendario. Permite aadir eventos dentro del curso. o Wiki. Esta herramienta permite el desarrollo de un documento en grupo. o Otras herramientas son: evaluciones, mensajes privados, correo, contenido Web, Gua del curso, etc. El servicio de autenticacin que proporciona Sakai soporta mecanismo de single signon, como Kerberos o LDAP

3.4.1

Desarrollo de aplicaciones o herramientas

Como se ha comentado Sakai est desarrollado en Java. As el lenguaje de programacin utilizado para desarrollar aplicaciones web ser Java Tambin, es importante mencionar que los desarrolladores, crean un entorno de trabajo para realizar sus aplicaciones, algunos de los componentes de este entorno son: Eclipse, un plug-in para Eclipse llamado Sakai AppBuilder plugin, maven (herramienta de software para la gestin y construccin de proyectos Java), etc. Por tanto, una herramienta de Sakai se desarrolla con un conjunto de herramientas. Y tiene la estructura que se indica en la figura 42. Es importante mencionar, que el esquema de datos con el que se trabaja, es el proporcionado por Sakai. Una vez creada la aplicacin, el administrador deber hacerla accesible desde Sakai

79

org.sakaiproject.nombre.aplicacion
Nombre.aplicacion (Interfaces) org.sakaiproject.nombre.aplicacion Acceso a datos Archivos de mapeo de hibernate Lgica de neocio Objetos de datos y valores (Implementacin) org.sakaiproject.nombre.aplicacion

(Definicin de componentes) (Pruebas) org.sakaiproject.nombre.aplicacion

(Herramienta) org.sakaiproject.nombre.aplicacion

Figura 42.

Estructura de un paquete [Sakai, 2009].

3.5

Claroline

Es una plataforma de aprendizaje de cdigo abierto y software libre (open source) que permite a los profesores construir eficaces cursos online y gestionar las actividades de aprendizaje y colaboracin en la web [Claroline, 2009]. Como se ha realizado en los anteriores LMSs, se describir la arquitectura de Claroline y posteriormente se mencionarn algunas de las aplicaciones y servicios que ofrece. La arquitectura de Claroline, est basada en: una base de datos, aplicaciones y servicios, y servidor Web.

La base de datos utilizada en Claroline es MySQL. En esta base de datos, que recibe el nombre de Claroline, se almacena la informacin relacionada con los cursos, usuarios, etc.

Las aplicaciones y servicios de Claroline estn hechos en php.

80

El servidor web. Normalmente el servidor Web utilizado es Apache, aunque tambin se puede usar el servidor de Microsoft Internet Information. A continuacin se describirn algunas de las herramientas ms importantes que ofrece Claroline:

Descripcin del curso. El profesor puede describir aspectos del curso, como objetivos, conocimientos y habilidades iniciales para iniciar el curso, etc.

Agenda. Donde se muestra un calendario y se puede aadir, modificar o borrar un evento de un curso.

Documentos o sistema de almacenamiento. Donde el profesor o estudiante puede cargar sus ficheros con informacin para el curso.

Ejercicios. Permite crear ejercicios online. Las cuestiones pueden ser: mltiple eleccin, de verdadero/falso, rellenar espacios en blanco o de relacionar conceptos. Es importante mencionar que Claroline soporta el estndar IMSQTI.

Camino de aprendizaje. Permite crear una secuencia de aprendizaje, pasos o actividades que el estudiante debe seguir. Este camino debe estar compuesto de al menos un mdulo (ejercicio, documento o SCORM). Tambin es posible ver los resultado de realizar un camino de aprendizaje (figura 43)

Chat. Permite que los participantes mantengan una conversacin en tiempo real (sncrono) a travs de Internet.

Wiki. Esta herramienta permite el desarrollo de un documento en grupo.

81

Figura 43.

Camino de aprendizaje.

Al igual que el resto de sistemas de gestin de aprendizaje, el servicio de autenticacin de claroline ofrece la posibilidad de autenticacin mediante su base de datos o bien mediante sistemas externos y single sign-on.

3.5.1

Desarrollo de mdulos en Claroline

Claroline, se instala en una carpeta con el mismo nombre, y se ubicar dentro de la carpeta htdocs de Apache. La carpeta claroline contendr todos los ficheros y directorios del kernel de Claroline, los mdulos, cursos, etc (figura 44).

Figura 44.

Estructura de directorios de claroline.

82

Un mdulo de Claroline al igual que en el resto de sistemas de aprendizajes es un paquete o directorio que contiene un conjunto de ficheros obligatorios y opcionales:

Ficheros obligatorios o manifest.xml. Describe el mdulo y contiene los datos necesarios para instalar y ejecutar el mdulo. o entry.php. Es el punto de entrada del mdulo y debe contener: 1. Identificador del mdulo. 2. Incluir el kernel de Claroline. 3. Incluir la lgica de negocio del mdulo. Es importante decir, que al igual que dotLRN, Moodle o Sakai, es necesario conocer las APIs que nos ofrece claroline, de tal forma que podamos llamar a funciones ya existentes y/u obtener datos de otros mdulos. Todo esto se hara dentro de la parte de lgica de negocio de entry.php. 4. Incluir la cabecera de Claroline 5. Mostrar al usuario la parte del mdulo visible para el. 6. Incluir el pie de pgina de Claroline.

Ficheros opcionales, como por ejemplo: ficheros de configuracin, libreras, hojas de estilo, etc. Lo ms probable es que el mdulo necesite utilizar la base de datos principal o de cursos, bien para crear o borrar tablas, o para obtener datos de ella. Para realizar esto, se crean los siguientes ficheros:

83

A nivel de base de datos principal. Los datos son compartidos a nivel de plataforma y los scripts solamente se ejecutan una vez. Por supuesto, este nivel tiene informacin sobre los cursos creados. o install.sql. Es ejecutado en la instalacin del mdulo y se utiliza para creacin de nuevas tablas. o unistall.sql. Es ejecutado cuando el mdulo es desinstalado y se utiliza para el borrado de tablas.

A nivel de cursos. Los datos son privados a un curso, no son compartidos y los scripts se ejecutan en cada acceso al mdulo. o course_install.sql. Es ejecutado en la instalacin del mdulo en un curso. o course_unistall.sql. Es ejecutado cuando el mdulo es desinstalado en un curso. Por ltimo, es necesario empaquetar el mdulo para que pueda ser instalado y utilizado. Los pasos a seguir seran: 1. Empaquetar el mdulo. Crear un zip con todos los ficheros del mdulo. 2. Instalar el mdulo (figura 45). 3. Activar y probar el mdulo en un curso.

84

Figura 45.

Instalacin de mdulos en Claroline.

3.6

Plataformas Privadas

Las plataformas que se acaban de ver son de software libre y/o cdigo abierto. De tal manera que cualquier programador de una institucin, puede conocer la arquitectura y programacin que la forman. Por tanto, puede modificarla o aadirle nuevas funcionalidades. Existen otro tipo de plataformas, que han surgido por iniciativa de empresas privadas, y que por tanto solamente pueden ser utilizadas (es muy difcil conocer su arquitectura y programacin y por tanto modificar o aadir cdigo). Hasta finales del 2005 y principios del 2006 existan dos sistemas de gestin de aprendizaje de iniciativa privada muy importantes:

WebCT. Plataforma desarrollada por Murray Goldberg, un miembro de la escuela de informtica de la Universidad de British Columbia en Canada. En 1997, Murray Goldberg cre la compaa Corporacin de Tecnologas Educativas WebCT para comercializar dicha plataforma. En 1999, WebCT fue adquirida por Tecnologas de Enseanza Universal, empresa afincada en

85

Boston (USA) y que llego a comercializar WebCT en ms de 80 pases, con un total de 10 millones de estudiantes.

Blackboard. Fue creada por la compaa Blackboard Inc. Esta naci con la fusin de Blackboar LLC (firma consultora con un contrato con el consorcio global de aprendizaje IMS) y CourseInfo (pequea compaa proveedora de programas de administracin de cursos originaria de la universidad de Cornell) LLC en 1998. Hasta 2005, Blackboard estaba siendo utilizada en ms de 2200 instituciones en ms de 60 pases. A principios de 2006 ambas empresas se fusionaron con el nombre de Blackboard Inc. Actualmente, esta empresa ofrece un conjunto de soluciones para la gestin de aprendizaje, de procesamiento de transacciones y comercio electrnico, y de comunidades online. A continuacin se enumerarn y describirn algunas de las lneas de trabajo de Blackboard Inc [blackboard, 2009].

Blackboard Academic suite. Esta solucin est compuesta de: o The Blackboard Learning System. Es un sistema de gestin de cursos. o Blackboard Community System. Es un sistema de portales y comunidades. o The Blackboard Content System. Es un sistema para la gestin de contenidos.

Los productos formados de la fusin con WebCT Inc: o Blackboard Vista. Es un sistema de gestin de cursos. o Blackboard Campus Edition. Es un sistema de gestin de cursos.

86

Blackboard Learn release 9. Es la ltima versin de la plataforma de aprendizaje de blackboard. Como todo LMS dependiendo del perfil de usuario se podrn realizar una serie de acciones. As: o El administrador de Blackboard Learn podr: gestionar usuario/grupos, crear y configurar cursos, etc (figura 46).

Figura 46.

Pgina inicial del Administrador en Blackboard Learn [Edugarage, 2009].

o El profesor de un curso en Blackboard Learn podr: gestionar sus cursos, crear tareas, establecer usuarios o grupos de usuario en el curso, etc (figura 47).

Figura 47.

Pgina inicial del profesor en Blackboard Learn [Edugarage, 2009].

87

o El estudiante de un curso en Blackboard Learn podr: crear sus propias carpetas, seguir el curso y los mdulos, utilizar las herramientas de colaboracin, etc (figura 48).

Figura 48.

Pgina inicial de un estudiante en Blackboard Learn [Edugarage, 2009].

Actualmente blackboard est permitiendo la creacin y desarrollo de mdulos y servicios Web por otros desarrolladores. Estos desarrolladores han debido hacer cursos para blackboard para conocer su arquitectura y programacin.

3.7

Comparativas entre LMS

Actualmente, un gran nmero de universidades e instituciones estn realizando estudios para valorar que sistema de gestin de aprendizaje es el ms adecuado para dar respuesta a sus necesidades. A continuacin se describen algunos de los estudios que se han llevado a cabo [Smithers, 2009] [Notas de Elearning, 2009]:

Universidad de Canterbury, Nueva Zelanda. Desde Octubre del 2007 hasta Octubre 2008 se evaluaron los LMS: Blackboard y Moodle. Este estudio aconseja Moodle [UC, 2008].

Universidad de McMaster, Canada. Desde Diciembre del 2006 hasta Abril del 2008 se evaluaron los siguientes LMS: Desire2Learn, Intrafinity, BlackBoard

88

Vista, Moodle y FirstClass. Este estudio aconsejo Blackboard Vista [McMaster, 2008].

University of North Carolina (Charlotte). Desde Enero del 2008 hasta Mayo del 2009 se evaluaron los LMS: Blackboard y Moodle [Croy, 2009]. Este estudio aconsejo Moodle y se enfoco en: o Aspectos pedaggicos. o Aspectos financieros. o Consideraciones sobre cdigo abierto, etc.

Universidad de Notre Dame. Desde Mayo del 2007 hasta Febrero del 2008 se evaluaron los LMS: Angel Learning Management Suite, Blackboard Vista, Sakai. Este estudio aconsejo Blackboard Vista Por ltimo, se van a mostrar un conjunto de tablas que muestra una comparativa de distintos LMS [Peris, 2008].

Tabla 3.1. Comparativa de herramientas de comunicacin de los LMS [Peris, 2008].

Foro

E-Mail

Chat

Pizarra

Bookmarks

dotLRN Moodle

Si Si

Si Si

Si Si

No Si

Si No

Claroline BlackBoard Sakai

Si Si Si

Si Si Si

Si Si Si

Si Si Si

No Si Si

89

Tabla 3.2. Comparativa de tipos de preguntas disponibles de los LMS [Peris, 2008].

Eleccin Rellenar Respuesta mltiple hueco corta

A desarrollar

Contiene media

Ordenar

dotLRN Moodle Claroline

Si Si Si

No Si Si

Si Si No

Si Si No

Si Si Si

No Si No

BlackBoard Sakai

Si Si

Si Si

Si Si

Si Si

Si Si

No No

Tabla 3.3. Comparativa de estndares de LMS [Peris, 2008].

IMS CP 1.1.3

IMS CP 1.1.4

QTI 1.2.1

QTI 2.0

SCORM 1.2

dotLRN Moodle Claroline BlackBoard

Si Si Si Si

Si Si Si No

Si No No Si

No No Si No

Si Si Si Si

Sakai

No

Si

Si

No

Si

90

3.8

Resumen

En este apartado se ha descrito la arquitectura general de un LMS. Para posteriormente, describir dos de los aspectos claves de los sistemas de aprendizaje de cdigo abierto ms conocidos (dotLRN, Moodle, Sakai y Claroline), como son: aplicaciones que ofrecen y como crear nuevas aplicaciones. En futuros captulos se mostrar como aportacin a esta tesis, la creacin y modificacin de algunos mdulos y paquetes de LMS de cdigo abierto, para proporcionar nuevas funcionalidades, en este caso la posibilidad de aadir laboratorios a los cursos proporcionados por los LMS.

91

92

CAPTULO 4.

LABORATORIOS VIRTUALES Y REMOTOS

4.1

Introduccin

Uno de los aspectos fundamentales en el desarrollo de una persona, es la adquisicin de conocimiento prctico o de habilidades. As, en muchas ocasiones de nuestra vida, es necesario aplicar nuestros conocimientos tericos para resolver problemas, manejar dispositivos, etc. En la enseanza tradicional, la adquisicin de habilidades o de conocimiento terico se obtena a travs de clases prcticas en un laboratorio. Hasta la llegada de los ordenadores y de Internet, los estudiantes de universidades o trabajadores de organizaciones con una metodologa de aprendizaje a distancia, deban desplazarse a algn centro donde poder realizar sus prcticas. La llegada de Internet, la mejora en las redes de comunicacin, la aparicin de lenguajes de programacin ms modernos y potentes, etc., han supuesto un gran cambio en la metodologa de aprendizaje a distancia y en la metodologa de aprendizaje mixto u blended learning. Los estudiantes, pasan de tener que desplazarse a laboratorios fsicos, a poder realizar sus prcticas desde cualquier lugar (casa, cibercaf, trabajo, etc.), bien utilizando programas de simulacin o manejando dispositivos fsicos de forma remota. Todo esto, junto con la llegada del Espacio Europeo de Educacin Superior donde se potencia la adquisicin de competencias en los estudios universitarios. Ha dado lugar, a la necesidad de creacin y utilizacin de laboratorios en el mbito de la educacin a distancia. En este captulo se describirn las posibles soluciones destinadas a que un estudiante o trabajador pueda adquirir, adems del conocimiento terico necesario, conocimiento

93

prctico desde un ordenador en cualquier momento y lugar. Estas soluciones reciben el nombre de laboratorios virtuales, laboratorios web y laboratorios remotos.

4.2

Simulacin

Antes de comenzar con la clasificacin de los tipos de laboratorios existentes, es conveniente describir uno de los conceptos claves de este captulo, el concepto de simulacin. Segn la real academia de la lengua, simular es: Representar algo, fingiendo o imitando lo que no es. Robert E. Shannon [Shannon, 1988] en su libro simulacin de sistemas: diseo, desarrollo e implementacin define simulacin como: El proceso de disear un modelo de un sistema real y realizar experimentos con l para entender el comportamiento del sistema o evaluar varias estrategias para la operacin del sistema Esta definicin tiene dos conceptos muy importantes: La creacin de un modelo y la realizacin de experimentos sobre ese modelo.

4.2.1

Creacin de un modelo

Un modelo de un objeto puede ser una rplica exacta de ste (aunque en un material diferente o escala diferente) o puede ser una abstraccin de las propiedades dominantes del objeto. Con el objetivo de ser [Shannon, 1988] [Elmaghraby,1968].

Una ayuda para el pensamiento. Es decir, la creacin del modelo nos pueden ayudar a organizar y clasificar conceptos confusos e inconsistencias del objeto o sistema.

94

Una ayuda para la comunicacin. Es decir, si un modelo est bien pensado y diseado facilita la comprensin a las personas que lo estudian. Es sabido que los lenguajes verbales dan lugar a ambigedades, mientras que otros modelos, como los matemticos, pueden disminuir dicha ambigedad.

Una ayuda para el entrenamiento e instruccin. Como por ejemplo, modelos de vehculos espaciales, etc. que permiten la instruccin de futuros astronautas.

Una herramienta de prediccin. Con la creacin de un modelo es posible predecir el comportamiento del objeto modelado.

Una ayuda para la experimentacin. El uso de modelos hace posible la experimentacin controlada en los experimentos que podran daar algn instrumento real, o bien en experimentos cuyo coste es muy elevado. Existen un gran nmero de clasificaciones de modelos de simulacin, en este apartado, se mencionar la clasificacin de A. J. Rowe, que clasifica los modelos segn el nivel de abstraccin que se aplica al crearlo (figura 49) [Rowe, 1963]. As, los modelos, de menor abstraccin a mayor, segn Rowe son:

tra tiv o

os

ala

gic

Sim u co laci mp n uta po do r r

fs ic

al

ae

mi

an

los

los

ad

los

de

de

os

de

Mo

Mo

eg

Mo

Exactitud

Ju

Abstraccin

Figura 49.

Clasificacin de modelos por A. J. Rowe [Shannon, 1988].

Modelos Fsicos. Son iguales en tamao y componentes fsicos al sistema u objeto real.

95

Mo

de

los

ma

tem

os

sc

nis

ti

co

Modelos a escala. Son modelos que se asemejan al modelo real, pero a una escala inferior o superior.

Modelos analgicos. Son aquellos modelos en los que una propiedad del objeto real est representada por una propiedad sustituida, que por lo general se comporta de manera similar. As, el problema se resuelve en el estado anlogo y se traslada a las propiedades originales.

Juegos administrativos. En estos modelos el hombre interacta con la salida del sistema para tomar decisiones. Estas decisiones posteriormente

realimentan el modelo como entrada del sistema.

Simulacin por computador. En los modelos anteriores los ordenadores pueden formar parte del modelo. En el modelo por computador, todo l, est realizado mediante ordenadores.

Modelos matemticos. Ya se ha visto que es un modelo y una clasificacin de los modelos de simulacin segn su nivel de abstraccin. Para finalizar con este apartado se har una breve descripcin de la estructura bsica de un modelo [Rios, 2008]. Aunque un modelo puede ser muy complicado matemticamente o fsicamente, su estructura fundamental es una combinacin de alguno de los siguientes elementos [Shannon, 1988]:

Componentes. Son las partes que forman el sistema.

Variables. En un sistema, es posible encontrarse dos tipos de variables: o Exgenas, tambin se llaman variables de entrada, y son variables que se originan fuera del sistema.

96

o Endgenas, tambin se llaman variables de estado o de salida, y son variables que se originan dentro del sistema.

Parmetros. Son valores que una vez asignados no varan. Por ejemplo en una ecuacin y=3x, x e y seran variables, mientras que 3 sera un parmetro.

Relaciones funcionales. Muestran el comportamiento de las variables y parmetros dentro de un componente o entre componentes del sistema.

Restricciones. Son limitaciones impuestas a los valores de las variables o a la manera en la cual los recursos pueden asignarse o consumirse.

Funciones de objetivo. Son una definicin explcita de los objetivos o metas del sistema y de cmo se evaluaran.

4.2.2

Experimentacin sobre el modelo creado

El propsito principal de la realizacin de estudios de simulacin es aprender todo lo que se pueda acerca del comportamiento del sistema que se est simulando al menor costo. Con el fin de lograr este objetivo, se deber planear y disear cuidadosamente, tanto el modelo como los experimentos que se ejecutarn sobre l. Este diseo experimental est compuesto, principalmente por los siguientes pasos: 1. Formular el problema a resolver. 2. Establecer los objetivos que se quieren obtener al realizar el experimento (para ello se debern establecer los valores iniciales ms adecuados para obtener los resultados ms significativos posibles). 3. Desarrollar el experimento y lenguaje de programacin ms adecuado. 4. Verificar que el modelo y lenguaje seleccionado en el punto tres es el adecuado

97

5. Desarrollar el experimento Para finalizar con el punto 3.2 se va a mostrar el proceso completo de simulacin (figura 50).

Establecer objetivos experimentales

Planificacin experimental preliminar

Restricciones del estudio (tiempo, etc.)

Origen del Problema

Formulacin del problema

Definicin del sistema Desarrollar modelo y cdigo de computadora Verificar y validar modelo y cdigo Desarrollar el plan y el diseo experimental final

Decisin para conducir el estudio

Decisin para usar el mtodo de simulacin Establecer restricciones del estudio y reglas del procedimiento

Implementar solucin

Analizar resultados

Generar datos experimentales a partir de ejecuciones de computo

Documentar resultado

Figura 50.

Proceso de Simulacin [Shannon, 1988].

4.3

Definicin y Tipos de Laboratorios

Segn la Real Academia de la Lengua, la palabra laboratorio tiene dos acepciones: 1. Lugar dotado de los medios necesarios para realizar investigaciones, experimentos y trabajos de carcter cientfico o tcnico. 2. Realidad en la cual se experimenta o se elabora algo. Como se ha comentado en anteriores apartados, El avance tecnolgico (redes, instrumentos de laboratorio, lenguajes de programacin, etc.) permite que estos

98

laboratorios puedan ser simulados o manejados de forma remota por cualquier estudiante o persona que tenga acceso a ellos. Este apartado, se va a centrar en dos puntos clave: definir los tipos de laboratorios existentes y los experimentos que se pueden realizar sobre ellos. Tipos de Laboratorios Aunque en posteriores apartados se tratar con ms detalle los diferentes tipos de laboratorios, es importante destacar los tres tipos existentes:

Laboratorios software. Son programas de simulacin que se pueden instalar y ejecutar en cualquier ordenador que cumpla con los requisitos de instalacin. No necesitan de conexin a Internet. De tal forma, que un estudiante podr instalar y llevar a cabo sus prcticas en cualquier momento y lugar.

Laboratorios Web. Son programas de simulacin que se ejecutan desde la web. Al estar en la Web, es necesario que el ordenador tenga conexin a Internet. Facilita herramientas de colaboracin como chats, foros, etc.

Laboratorios Remotos. Son programas que permiten manejar instrumento de forma remota. As, un estudiante podr llevar a cabo sus prcticas, con instrumentos reales, desde cualquier ordenador con un navegador y con conexin a Internet. Es importante sealar que estos laboratorios no son independientes. Sino que pueden utilizarse de forma conjunta. As, es posible utilizar un laboratorio web o software (de simulacin) para que el estudiante adquiera un manejo correcto de los instrumentos (permitirle hacer operaciones incorrectas con ellos, etc.), y posteriormente, una vez que conoce el manejo de los instrumentos, permitirle acceder a los instrumentos reales utilizando laboratorios remotos [Naef, 2006].

99

Tambin, es importante indicar que en muchos casos las organizaciones e instituciones que crean laboratorios, no se limitan a su creacin, sino que crean un conjunto de servicios que complementan al laboratorio (figura 51). Algunos de estos servicios son:

Interfaz de Usuario

Autenticacin Herramientas de Evaluacin Contenidos (No SCORM) Laboratorio

Herramientas de Comunicacin

Servicio de reservas

Grupos y Gestin de Perfiles

Gestin de Logs de Experimentos

Logs

Figura 51.

Servicios que normalmente rodean a un laboratorio Web o remoto.

Servicio de autenticacin para acceder al experimento o experimentos.

Servicios de comunicacin (chats, foros) para proporcionar trabajo colaborativo.

Herramientas de evaluacin para evaluar al estudiante. Normalmente no utilizan estndares e-learning (IMS-QTI).

Herramientas para mostrar contenido acerca del experimento a realizar o de la teora que el estudiante debe conocer antes de realizar el experimento. Normalmente no utilizan estndares e-learning (SCORM, IMS-CP, etc.)

Servicio de reservas. Actualmente se utiliza un servicio de reservas para cada laboratorio o experimento. Sera interesante que este servicio pudiera ser

100

comn a diferentes laboratorios y experimentos. Y que un usuario o estudiante pudiera reservar en cualquier laboratorio de cualquier institucin de una manera sencilla y global. Estos y otros servicios son creados una y otra vez cuando un laboratorio es desarrollado por una institucin. No existe reutilizacin. Tipos de Experimentos Un aspecto importante es la definicin de experimentos sobre un laboratorio. Es posible dividir estos en tres grupos [Hardward, 2004][Saire, 2008]: 1. Experimentos por Lotes o Batch. El estudiante, antes que empiece el experimento, especifica todos los parmetros que gobiernan la ejecucin de este. Normalmente a travs de un fichero, este fichero se manda al laboratorio y es ejecutado cuando este est libre, devolviendo los resultados. Suelen ser experimentos de poca duracin y suelen estar gestionados por colas. 2. Experimentos con sensores. El estudiante, normalmente, no puede especificar ningn parmetro de un sensor. En la ejecucin del experimento se recibe la informacin en forma digital o en grficos de tendencias. Este tipo de interfaces a veces muestran herramientas para filtrar o procesar posteriormente la informacin, como en el caso de aquellas que permiten activar alarmas o envo de notificaciones por e-mail. 3. Experimentos interactivos. El estudiante configura una serie de parmetros, inicia el experimento y luego monitoriza su desarrollo, pudiendo cambiar los parmetros de control si es necesario. Un experimento interactivo puede ser concebido conceptualmente como una secuencia de intervalos de

monitorizacin y ajustes de control. El acceso a estos experimentos se puede gestionar mediante calendarios o permitiendo la concurrencia.

101

4.4

Laboratorios Software

Un laboratorio software, es un programa de ordenador que simula sistemas, dispositivos y situaciones del mundo real que un estudiante o trabajador se puede encontrar en su vida laboral, y que debe saber manejar y resolver con xito. Por tanto, el estudiante solo necesita un ordenador sin conexin a Internet, que tenga instalado el programa para llevar a cabo sus prcticas (figura 52).

1. Instalar el software del laboratorio en el PC del estudiante 2. Realizar los experimentos, utilizando dicho software

Estudiante

Figura 52.

Laboratorio Software.

4.4.1

Ventajas y Desventajas de los Laboratorios Software

A continuacin se pasar a enumerar las ventajas y desventajas de este tipo de laboratorios. Las principales ventajas son: 1. Existen sistemas demasiado caros para que cualquier organizacin o universidad disponga de ellos. En estos casos, los programas de simulacin permiten que los miembros de estas organizaciones y universidades puedan conocer y manejar dichos sistemas. Disminuyendo el coste (compra y mantenimiento) del sistema. 2. Los estudiantes pueden instalar el software en cualquier ordenador y realizar sus prcticas en cualquier momento y lugar (24 horas al da, 7 das a la semana y 365 das al ao).

102

3. Cuando se trabaja en un laboratorio fsico, existe riesgo de que algn estudiante pueda daar algn dispositivo caro. Los programas de simulacin permiten: a. Al profesor, disear experimentos que puedan daar el sistema. Por ejemplo, realizar una primera prctica para que el estudiante vea cmo funciona el sistema y que errores fatales podran aparecer de un mal uso del sistema. b. Al estudiante, realizar sus prcticas sin temor de poder equivocarse y provocar algn dao a los dispositivos. 4. En muchas organizaciones y universidades existen laboratorios fsicos que son compartidos por varias asignaturas con un gran nmero de estudiantes. Esto supone que solo se puedan hacer un nmero limitado de experimentos por estudiante. Los programas de simulacin, permiten que un estudiante pueda realizar un mayor nmero de experimento y de cada experimento un gran nmero de ensayos. Las principales desventajas de este tipo de laboratorio son: 1. El estudiante no trabaja con dispositivos reales. Aunque el modelo y los experimentos estn bien diseado, nunca ser lo mismo que trabajar con los dispositivos reales. 2. Problemas de versiones. Como se ha comentado anteriormente, el PC no necesita una conexin a Internet para realizar sus prcticas. Por tanto, el estudiante obtendr las nuevas versiones del software a travs de algn dispositivo fsico (CD, etc.). Lo que puede dar lugar a que haya estudiantes que trabajen con versiones diferentes.

103

Para resolver este problema el ordenador del estudiante debera tener una conexin a internet y la institucin o universidad ofrecer un servidor de versiones a travs de Internet, donde el estudiante pudiera descargarse las ltimas versiones del software (figura 53).

Nuevas versiones del laboratorio 1. Instalar SW en el PC del estudiante Internet 2. Realizar los experimentos, utilizando dicho software Estudiante Servidor Web

Figura 53.

Laboratorio Software con descarga de versiones.

3. No existen herramientas colaborativas. El estudiante realiza sus prcticas o experimentos de forma individual, y aislado de sus compaeros y del profesor. 4. No existe posibilidad de que el tutor pueda evaluar de forma continua los progresos realizados por el estudiante. Ya que este realiza sus prcticas de manera aislada y no se puede evaluar el nmero de horas dedicadas al estudio, en nmero de ensayos realizados, etc.

4.4.2

Lenguajes de programacin y ejemplos de Laboratorios Software

Un laboratorio software es una aplicacin de escritorio donde el usuario pueda realizar sus prcticas. Y dependiendo de la complejidad del sistema, del lenguaje de programacin utilizado, del sistema operativo donde se ejecute, etc. la aplicacin ser ms ligera o pesada. Existen una gran variedad de lenguajes de programacin y de metodologas de programacin, que permiten ayudar en el diseo y creacin de una aplicacin de escritorio (C, C++, JAVA, Visual Basic, MathLab, LabView, Simulink etc.). Por tanto, antes de empezar a programar, ser conveniente seleccionar el lenguaje de programacin ms adecuado. Esta eleccin viene dada por muchos aspectos que hay

104

que tener en cuenta: acceso a base de datos, diseo grfico, curva de aprendizaje, etc. Tambin, existen un gran nmero de programas de simulacin (incluidos juegos), ya desarrollados, que facilitan la adquisicin de conocimiento y habilidades. A continuacin vamos a ver un par de aplicaciones de escritorio de libre distribucin.

RCSim. Es un simulador de circuitos resistivos, permite el diseo del circuito directamente en pantalla y cuenta con instrumentos de medicin que muestran los valores de voltaje y corriente mientras se ejecuta la simulacin.Los clculos se hacen basados en el Anlisis Nodal Modificado [Sibees-RCSim, 2009]. Una vez que el estudiante instala el programa y lo ejecuta. Le aparecer un entorno de trabajo, donde el estudiante, podr crear sus propios circuitos y comprobar o simular su funcionamiento de dicho circuito (figura 54).

Herramientas para disear el circuito

Iniciar y parar simulacin del circuito

Circuito que se ha creado

Figura 54.

Entorno de trabajo de RCSim.

VLabQ. Es un simulador interactivo de prcticas de laboratorio de Qumica. Contiene los instrumentos necesarios al igual que un Laboratorio real, tales como: Vasos de Precipitados, Matraces Erlenmeyer, filtro buchner, Matraz de

105

baln, Reactor, Buretas, Probetas, Pipetas, Tubo de ensaye, etc. Adems de equipo de medicin: como pHmetros, termmetros, conductmetros y balanzas. Equipo trmico: mechero, parrilla y Bao de hielo. Agitador de vidrio, vidrio de reloj, Cpsula de porcelana, Calormetro [Sibees-VLabQ, 2009]. Una vez que el estudiante instala el programa y lo ejecuta. Le aparecer un entorno de trabajo, donde el estudiante, podr realizar la prctica de qumica diseada por el profesor (figura 55).

Herramientas y mens para realizar la prctica

Cambiar la velocidad de simulacin

Prctica realizada por el alumno

Documento del profesor que explica como realizar la prctica y posteriormente le pregunta sobre los resultados obtenidos

Figura 55.

Entorno de trabajo de VLabQ.

Estos laboratorios permiten que el estudiante pueda adquirir habilidades y conocimiento desde su casa, pero, an as, les faltan dos componentes muy importantes: 1. Herramientas de comunicacin con otros estudiantes y de colaboracin. 2. Trabajar con instrumentacin real.

106

4.5

Laboratorios Web

En este tipo de laboratorios, el estudiante no necesita instalar el programa de simulacin en su ordenador, tal vez algn plug-in. As, este se conectar a un servidor web, que es el encargado de servir el programa de simulacin. Es necesario un PC con conexin a Internet (figura. 56).

Estudiante Internet Servidor Web Estudiante 1. Navegador Web 2. Applet de Java o aplicacin Web del laboratorio

1. Servicios Web a) Registro de usuarios b) Herramientas de comunicacin, etc. 2. Laboratorio virtual (parte Servidor)

Figura 56.

Laboratorio Web.

4.5.1

Ventajas y Desventajas de los Laboratorios Web

A continuacin se pasar a enumerar las ventajas y desventajas de este tipo de laboratorios. Las principales ventajas son: 1. Existen sistemas demasiado caros para que cualquier organizacin o universidad disponga de ellos. En estos casos, los programas de simulacin permiten que los miembros de estas organizaciones y universidades puedan conocer y manejar dichos sistemas. Disminuyendo el coste (compra y mantenimiento) del sistema. 2. Los estudiantes pueden instalar el software en cualquier ordenador y realizar sus prcticas en cualquier momento y lugar (24 horas al da, 7 das a la semana y 365 das al ao).

107

3. Cuando se trabaja en un laboratorio fsico, existe riesgo de que algn estudiante pueda daar algn dispositivo caro. Los programas de simulacin permiten: a. Al profesor, disear experimentos que puedan daar el sistema. Por ejemplo, realizar una primera prctica para que el estudiante vea cmo funciona el sistema y que errores fatales podran aparecer de un mal uso del sistema. b. Al estudiante, realizar sus prcticas sin temor de poder equivocarse y provocar algn dao a los dispositivos. 4. En muchas organizaciones y universidades existen laboratorios fsicos que son compartidos por varias asignaturas con un gran nmero de estudiantes. Esto supone que solo se puedan hacer un nmero limitado de experimentos por estudiante. Los programas de simulacin, permiten que un estudiante pueda realizar un mayor nmero de experimento y de cada experimento un gran nmero de ensayos. 5. El servidor web, aparte de proporcionar el programa de simulacin, ofrece herramientas de autenticacin y comunicacin entre estudiantes, tanto sncrona (chat, etc.), como asncrona (foros, etc.) 6. Permite al profesor seguir los progresos de los estudiantes, a travs de los Logs y de los resultados de sus experimentos. La principal desventaja de este tipo de laboratorio es que el estudiante no trabaja con dispositivos reales. Aunque el modelo y los experimentos estn bien diseado, nunca ser lo mismo que trabajar con los dispositivos reales.

108

4.5.2

Tecnologas Web utilizadas y ejemplos de laboratorios Web

Existe un gran abanico de tecnologas que permiten el desarrollo de aplicaciones Web. A diferencia de las aplicaciones de escritorio, las aplicaciones web nos ofrecen una serie de ventajas con respecto a las anteriores:

Es posible acceder a la aplicacin desde cualquier ordenador que tenga una conexin a Internet.

A diferencia de las aplicaciones de escritorio, no es necesario que tengan permisos de lectura y escritura sobre el ordenador del usuario. Antes de comenzar a ver algunos ejemplos de laboratorios Web, se describirn brevemente algunas de las tecnologas ms utilizadas en la creacin de laboratorios Web [Garca-Zubia, 2007].

ActiveX. Es una tecnologa Microsoft creada a mediados de los 90 que permite la creacin de pequeos programas que pueden ser bajados y ejecutados en Internet Explorer [Codeproject, 2009] [Microsoft-Activex, 2009]. Es una tecnologa muy potente, pero presenta algunos problemas muy significativos: o Son programas intrusivos. Requieren permisos de escritura y lectura. o Problemas de compatibilidad con otros navegadores

Applets de Java. Un Applet es un componente de una aplicacin, en este caso Java, que se ejecuta en el contexto de otra aplicacin, normalmente un navegador Web. Para ejecutar un Applet de Java en el navegador, es necesario que el usuario tenga instalado en su ordenador el plug-in del entorno de ejecucin de Java o JRE. En algunos casos, an teniendo instalado una versin de JRE, puede no funcionar (problemas de versin).

109

Como ventajas se puede decir que es multiplataforma, lo soportan casi todos los navegadores y no es tan intrusivo como el ActiveX [Java-Sun-Oracle, 2009].

Plataforma Adobe Flash. La plataforma Flash combina un conjunto de herramientas profesionales [Flash, 2009], como: o Flash CS4 profesional que ofrece un entorno para generar contenidos interactivos [Gerantabee, 2009]. o Adobe Flash media Server. Es una familia de productos que dan solucin al envi continuo de video y a la comunicacin en tiempo real. o Adobe AIR. Permite utilizar tecnologas web, como AJAX, para crear aplicaciones de escritorio. La plataforma Flash es compatible con tecnoogas .NET y Java, adems de ser soportado por casi todos los navegadores (es necesario la instalacin de un plug-in en el cliente) [Flash, 2009].

AJAX. Son las siglas de Asynchronous JavaScript And XML, como su propio nombre indica, AJAX no es propiamente una tecnologa sino una manera de trabajar con varias tecnologas ya existentes [Garret, 2005] (figura 57), como: o Modelo de Objetos para la representacin de Documentos o DOM. o XHTML y CSS, para crear una presentacin basada en estndares. o XMLHttpRequest, para el intercambio asncrono de informacin. o XML, XSLT y JSON, para el intercambio y la manipulacin de informacin. o JavaScript, para unir todas las dems tecnologas.

110

Modelo Clsico de aplicaciones Web

Modelo de aplicaciones Web usando AJAX

Navegador del Usuario Navegador del Usuario

Interfaz de usuario Interfaz de usuario Llamada JavaScript HTML + CSS datos Motor AJAX HTML + CSS datos

Transporte http(s)
Peticin http Servidor Web Interfaz de usuario

Datos XML

Transporte http(s)
Peticin http Servidor Web o XML Almacn de datos, sistemas existentes...

Figura 57.

Modelo de Aplicaciones Web y de aplicaciones Web en AJAX [Garret, 2005].

Como podemos ver AJAX trabaja con estndares (XML, CSS, etc.) y tecnologas soportadas por la gran mayora de los navegadores.

HTML y CSS. Las aplicaciones que utilizan esta tecnologa, no tienen por s mismas capacidad de interaccin. Por lo que sera necesario, incluir algn lenguaje de Scripting (JavaScript, vbscript, php, etc.) para aadir interaccin. Como ya se ha comentado anteriormente la eleccin de una tecnologa vendr dada por muchas razones: facilidad de uso, facilidad de aprendizaje, potencia del lenguaje, aspectos de seguridad, etc. Para finalizar con este apartado, se van a describir brevemente algunos de los laboratorios Web que se ofrecen a travs de Internet:

111

Laboratorio web para la creacin de circuitos lgicos realizado por la universidad Johns Hopkings. Cuyo objetivo es permitir al estudiante crear y disear sus propios circuitos lgicos. Para ello, el estudiante utilizar una serie de elementos de la lgica binaria (figura 58). Un ejemplo de prctica para este laboratorio, sera la creacin de circuitos que realicen alguna operacin matemtica como: suma, resta, o la multiplicacin. [Hopking, 2009].

Figura 58.

Puertas lgicas ofrecidas por el laboratorio web [Hopking, 2009].

Este Laboratorio es un Applet de Java (figura 59). Para acceder a dicho laboratorio, el estudiante solo deber disponer de un navegador y del plug-in de java.

Figura 59.

Applet para el manejo del laboratorio web [Hopking, 2009].

La web fisquiweb destinada al aprendizaje de la fsica y qumica, ofrece un conjunto de material didctico y de laboratorios para el aprendizaje de esta asignatura [Fisquiweb, 2009]. Un ejemplo, es el laboratorio destinado a explicar la ley de Ohm, para ello el estudiante crea un circuito (arrastrando elementos de la pgina Web) y comprueba el resultado de aplicar dicha ley (figura 60).

112

Figura 60.

Laboratorio Web hecho en Flash [Fisquiweb, 2009].

Todos los laboratorios ofrecidos en esta pgina estn realizados en Flash. Para acceder a estos laboratorios, el estudiante solo deber disponer de un navegador y del plug-in de Flash.

Laboratorio Web del departamento de Ingeniera Elctrica, Electrnica y de Control de la Universidad Nacional de Educacin a Distancia (UNED). Que permite a un estudiante simplificar funciones lgicas por el mtodo de Karnaugh [dieec, 2009]. Este Laboratorio es un Applet de Java (figura 61). Para acceder a dicho laboratorio, el estudiante solo deber disponer de un navegador y del plug-in de java.

Figura 61.

Laboratorio Web hecho en Java.

113

4.6

Laboratorios Remotos

El estudiante se conecta a un servidor web, este le mostrar las imgenes reales de los instrumentos que va a manejar, las acciones que puede realizar y los resultados de esas acciones. La arquitectura bsica de un laboratorio remoto est formada por los siguientes elementos, (figura 62) [Ko, 2004]:

El controlador va enviar las ordenes a los instrumentos y recibir los resultados de la ejecucin de estos comandos. Servidor de Audio/video

Estudiante Internet Servidor Web Estudiante 1. Navegador Web 2. Applet de Java o aplicacin Web del laboratorio Servidor de Base de datos 1. Servicios Web a) Registro de usuarios b) Herramientas de comunicacin, etc. 2. Laboratorio virtual (parte Servidor) Controlador ? ? Instrumentos

1. Permite almacenar a) Los datos del usuario b) Datos del experimento, etc.

Figura 62.

Arquitectura general de un laboratorio remoto.

Ordenador del Estudiante. El estudiante necesita un ordenador con conexin a Internet y accede al laboratorio utilizando un navegador. Este navegador cargar la aplicacin web del laboratorio (Applet, ActiveX, etc.).

Servidor Web. Es uno de los elementos clave de la arquitectura. Sus funciones son: o Atender y responder las peticiones http realizadas por el navegador del estudiante. enviar las pginas, applets o activeX del laboratorio, recibir las acciones a realizar en el laboratorio, enviar las respuestas de las acciones realizadas en el laboratorio, etc.

114

o Ofrecer servicios complementarios al laboratorio y al usuario que se conecta al laboratorio, como: autenticacin, autorizacin, herramientas de comunicacin, reservas, plantas hidrulicas, etc. o Enviar los comandos indicados por el estudiante al controlador y recibir las respuestas de este.

Controlador. Es un ordenador conectado a los instrumentos del laboratorio, suelen conectarse a travs de tarjetas de adquisicin de datos o DAQ, buses de interfaz de propsito general o GPIB, una interfaz RS-232, etc. El controlador debe: 1. Recibir, del servidor Web, los comandos que deben ejecutar los instrumentos. 2. Convierte estos comandos en seales y los enva a travs de la tarjeta de adquisicin, bus GPIB, etc. 3. Recibe las seales de respuesta y las transforma para el servidor Web.

Instrumentos. Existe una gran variedad de hardware que puede ser conectado a un ordenador y manejado de forma remota. Algunos ejemplos son: Osciloscopios, analizadores de espectro,

Servidor de Audio y Video. Es el encargado de servir el audio y video del laboratorio fsico al estudiante, de tal forma que este vea las respuestas del instrumento a sus rdenes. Podra ser parte del servidor Web.

Servidor de base de datos. Las bases de datos podran estar incluidas en el servidor. Pero por motivos de mantenimiento, escalabilidad y seguridad, es preferible que este fuera de l. Contiene la informacin necesaria para el sistema como: estudiantes, prcticas, resultados, etc.

115

4.6.1

Ventajas y Desventajas de los Laboratorios Remotos

A continuacin se pasar a enumerar las ventajas y desventajas de este tipo de laboratorios. Las principales ventajas son: 1. El estudiante o usuario trabaja con instrumentos reales, no con programas de simulacin. 2. Los estudiantes pueden acceder al laboratorio en cualquier momento y en cualquier lugar (si disponen de conexin a Internet). Por tanto, los instrumentos adquiridos por las universidades u organizaciones pueden ser utilizados, aunque sus instalaciones estn cerradas. Para acceder a estos laboratorios se crean un conjunto de servicios: o Autenticacin. Que consiste en comprobar que el usuario y el estudiante puede acceder al laboratorio. o Autorizacin. Una vez autenticado hay que comprobar a que experimentos tiene acceso. o Reservas. En la mayora de los casos, los experimentos sobre laboratorios no soportan concurrencia, por lo que es necesario crear un servicio de reservas que controle el acceso a un experimento por los estudiantes. Dos de los mtodos ms utilizados actualmente son: Gestin de colas. Normalmente es utilizado en los experimentos por lotes o batch.

116

Gestin de un calendario. El estudiante puede reservar el da y la hora para realizar el experimento. Normalmente es utilizado en experimentos interactivos.

3. El servidor Web, adems del laboratorio, puede ofrecer una serie de servicios: autenticacin, herramientas de comunicacin, de colaboracin, etc. 4. Permite al profesor seguir los progresos de los estudiantes, a travs de los Logs y de los resultados de sus experimentos. Desventajas: 1. Es importante disear e implementar de manera correcta los experimentos que va a hacer el estudiante. Al manejar instrumentos reales, cualquier operacin inadecuada podra daar el instrumento o instrumentos. 2. Aun con la mejora en las conexiones de red, es importante definir bien los formatos de video y audio. Evitando retrasos o perdidas de audio y video no deseadas

4.6.2

Tecnologas Web utilizadas y ejemplos de laboratorios remotos

Las tecnologas utilizadas son las mismas que en los laboratorios Web: ActiveX, Applets de Java, Ajax, etc. A continuacin se describirn algunos de los laboratorios remotos ms

representativos. WebLab-Deusto Version 3 La universidad de Deusto cre una arquitectura y conjunto de laboratorios remotos con el nombre de WebLab-Deusto. Esta arquitectura fue de las primeras en aplicar el

117

paradigma de la Web 2.0 y en adoptar la Arquitectura Orientada a Servicios, a travs de su adaptacin a los laboratorios remotos conocida como SOLA [Ordua, 2007]. WebLab-Deusto ha sido desplegado para tres tipos de experimentos:

WebLab-PLD. Es utilizado en la asignatura de lgica programable (figura 63).

Figura 63.

Laboratorio Remoto WebLab-PLD de la universidad de Deusto.

WebLab-FPGA [Garca-Zubia, 2009]. Utilizado en la asignatura de diseo electrnico.

WebLab-GPIB. Utilizado en la asignatura de instrumentacin electrnica. La arquitectura hardware de WebLab-Deusto es muy similar a la arquitectura general de un laboratorio remoto. En la figura 64, se puede ver cada uno de los componentes que la forman. Sin embargo, es la arquitectura software lo que diferencia a la mayora de los laboratorios remotos. WebLab-Deusto sigue una arquitectura basada en capas que le permite una mayor escalabilidad, seguridad y mantenimiento. A continuacin se describir cada una de estas capas: 1. Capa de presentacin. Servidor web y cdigo que haga accesible la lgica de negocio a travs de una pgina web AJAX.

118

Figura 64.

Arquitectura hardware de WebLab-Deusto [Ordua, 2007].

2. Capa de negocio. Est formada por tres servidores: a. Servidor de login, que gestione el inicio de sesiones a travs de los mecanismos necesarios: base de datos, LDAP, etc. b. Servidor de procesamiento de usuarios, que gestione el grueso de las operaciones de la lgica de negocio. c. Servidor de coordinacin, que registren los diferentes servidores disponibles de distintos tipos. 3. Capa de acceso a datos. La forman: a. Servidor de base de datos, que abstraiga al resto de servidores las operaciones de alto nivel y gestione la base de datos. b. Gestor de base de datos, que consiste en el servidor de MySQL. 4. Capa de experimentos. La forman: a. Servidor secundario, que abstraiga al resto del WebLab del sistema montado en el laboratorio. Estos servidores secundarios interactuarn

119

directa o indirectamente con el hardware, efectuando las operaciones que los servidores de procesamiento de usuarios soliciten. Tambin es importante mencionar que WebLab-Deusto V3 soporta los protocolos SOAP y Direct. Laboratorio Experimental a Distancia de Fsica Electrnica Es un laboratorio remoto de la universidad de Rosario, Argentina (figura 65). El objetivo de este laboratorio es obtener las curvas caractersticas de:

Diodo en polarizacin directa.

Diodo Zener.

Transistor bijuntura en conexin emisor comn.

Figura 65.

Pgna HTML del Laboratorio Remoto [Lerro, 2008].

J-Fet.

Fototransistor.

120

En la figura 66 se muestra la arquitectura hardware que sigue dicho laboratorio. Como se ve en dicha figura, en este caso no existe envi de audio y video, ni un servidor de base de datos. Lo realmente interesante de este laboratorio, es que al usuario le devuelve una pgina HTML (figura 67). Por tanto cualquier navegador, sin necesidad de ningn plug-in, instalado en cualquier sistema operativo puede visualizarlo sin problemas.

PC

Internet
PC

Tarjeta DAQ

Servidor
PC
Conmutador y elementos con los que se va a experimentar

Figura 66.

Arquitectura Hardware del Laboratorio Remoto [Lerro, 2008].

Peticin de usuario

Servidor

PC de usuario

Entradas digitales

Salidas analgicas

Figura 67.

Esquema de trabajo del Laboratorio Remoto [Lerro, 2008].

Proyecto VISIR (Virtual Instrument Systems in Reality) El proyecto VISIR fue iniciado, en 2006, por el Instituto de Tecnologa Blekinge de Suecia y la institucin Americana National Instrument [VISIR, 2009]. El objetivo de este proyecto era crear laboratorios distribuidos en lnea en colaboracin con otras

121

universidades (Deusto, etc.). Para ello se pretenda desarrollar una mesa de trabajo o workbench on line que permitiera al estudiante realizar experimentos elctricos desde su casa (figura 68) [Gustavsson, 2007].
Mesa de trabajo tradicional

Mesa de trabajo on-line

Figura 68.

Workbench tradicional y on-line.

Como se puede ver en la figura 68, la mayora de los aparatos elctricos que se ven pueden ser controlados remotamente, pero Qu pasa con la placa y los cables que se colocarn sobre ella? Para imitar esto, el instituto tecnolgico de Blekinge ha diseado una matriz de conmutacin con rels electromecnicos que simulan dicha placa y cables. As la estructura creada sera un PC desde donde el estudiante ve la placa simulada, el panel frontal de un osciloscopio, etc. Y un PC encargado de construir el circuito, usando la matriz de conmutacin (figura 69) Dos de los aspectos ms destacables de este laboratorio son: Proporciona una interfaz grfica con un gran nmero de dispositivos electrnicos (muy detallada y fcil de completar, aadir elementos) y la posibilidad de que varios estudiantes puedan realizar sus prcticas de forma simultnea (concurrencia).

122

Estudiante

Mesa de trabajo

Placa simulada

Matriz de conmutacin

Figura 69.

Implementacin de la mesa de trabajo on-line.

Laboratorio Remoto de una pequea Planta Hidrulica del Departamento de Ingeniera Elctrica, Electrnica y de Control de la UNED Este laboratorio permite a los estudiantes realizar los experimentos ofrecidos en Labview para una planta hidrulica (figura 70). Este laboratorio consta de la planta hidrulica, con sensores, actuadores y una tarjeta de adquisicin de datos que permite comunicarse con un ordenador a travs del puerto serie (figura 71)

Figura 70.

Planta Hidrulica de FESTO.

El lenguaje utilizado para programar y llevar a cabo las prcticas ha sido realizado en Labview. El estudiante por tanto necesitar instalar en su navegador un plugin para llevar a cabo sus prcticas.

123

Figura 71.

Arquitectura del laboratorio remoto de una planta hidrulica.

4.7

Comparativa entre los diferentes tipos de laboratorios

Como se acaba de ver en este captulo existen tres tipos de arquitectura para los laboratorios. Estas arquitecturas pueden ser empleadas de forma conjunta a la hora de realizar un conjunto de prcticas. As un laboratorio software puede ser utilizado para dar a conocer al estudiante los instrumentos que posteriormente va a utilizar en un laboratorio remoto. En la tabla 4.1 se muestran algunas de sus caractersticas ms significativas.

Tabla 4.1. Caractersticas de los diferentes tipos de laboratorios.

Laboratorios Software

Laboratorio Web

Laboratorio Remoto

Dispositivos simulados

Si

Si

No

Dispositivos Reales

No

No

Si

Conexin a INTERNET

No

Si

Si

Herramientas Colaborativas

No

Si

Si

Problemas de versiones

Si

No

No

Seguimiento del estudiante

No

Si (blogs)

Si (blogs)

Hacer un experimento

Cualquier momento

Cualquier momento

Cualquier momento

124

4.8

Resumen

En este captulo se han descrito los diferentes tipos de laboratorios que existen y sus caractersticas. Tambin se ha visto que cada universidad crea sus propios laboratorios. En algunos casos laboratorios muy parecidos o exactamente iguales. As, imagine tres universidades que quieren desarrollar un laboratorio remoto para el manejo de una planta hidrulica. Cada una de ellas debera dedicar gran parte de los recursos (monetarios, personal, materiales, etc.) para crear lo ya creado. Entonces, por qu no permitir la utilizacin de estos laboratorios por esas tres universidades? Por qu no reutilizar cdigo o usar una arquitectura similar? Esta y otras cuestiones estn siendo tratadas. Iniciativas como el WebLab de Deusto o Visir intentan que sus experimentos puedan ser reutilizados por estudiantes de diferentes asignaturas o universidades. En el siguiente captulo se hablar del proyecto iLab del MIT, cuya idea fue el diseo y desarrollo de una arquitectura que permitiera compartir laboratorios remotos online

125

126

CAPTULO 5.

ARQUITECTURA ILAB

5.1

Introduccin

Como se ha visto en el capitulo anterior, existen un gran nmero de universidades y organizaciones que han o estn desarrollando sus laboratorios web. En la mayora de los casos, estos laboratorios solo pueden ser utilizados por los estudiantes de dicha universidad u organizacin. El Instituto tecnolgico de Massachusetts (MIT) junto con Microsoft y Agilent Technologies inici el proyecto iLab en el ao 2000 con el objetivo de establecer un marco de trabajo que facilitar el desarrollo, gestin y comparticin de laboratorios remotos online (iLabs) [iLabs, 2010] Actualmente esta arquitectura permite que estudiantes de diferentes universidades del mundo (Nigeria, China, Australia, Austria, etc.) puedan compartan sus laboratorios.

5.2

Arquitectura para Compartir Laboratorios Online o iLab

La arquitectura desarrollada por el proyecto iLab, recibe el nombre de ISA (iLab Shared Architecture) [ISA, 2010]. A grandes rasgos podemos indicar que la arquitectura ISA divide un laboratorio online en tres partes [Hardison, 2008] (figura 72): 1. El cliente del laboratorio. Que no es ms que la interfaz de usuario para el laboratorio online o iLab. 2. El servidor del laboratorio conecta con el hardware del laboratorio y gestiona el experimento enviado por el usuario. 3. El servicio Broker. Mientras que los anteriores contienen funcionalidades especficas para cada laboratorio, ste, es responsable de proporcionar las funcionalidades comunes para todos los laboratorios online, como:

127

autenticacin y autorizacin, almacenamiento de datos, etc. Cada universidad dispone de un servicio Broker.

Servidor de laboratorio 1

Servicio Broker

Internet

Red del campus

Clientes

Servidor de laboratorio 2 Red del campus

Servidor de laboratorio n

Figura 72.

Arquitectura iLab [ISA, 2010].

Esta arquitectura est basada en servicios Web, de tal forma que se proporcione un marco de trabajo software que permita soportar un gran nmero de laboratorios online. As, se puede decir que la arquitectura ISA es:

Escalable, en el sentido que reduce el trabajo del proveedor del laboratorio.

Descentralizado, en el sentido de que cada organizacin maneja las cuentas de sus estudiantes, el calendario de acceso a los laboratorio, el almacenamiento de datos, etc.

Segura, en el sentido que proporciona un mecanismo de autorizacin cifrada y control de acceso.

Abierta, en el sentido de disponer de una especificacin abierta de un conjunto de servicios web y protocolos estndares como HTML, SOAP, WSDL, etc.

Compatible, en el sentido de permitir a los usuarios de software comercial, en particular, LabVIEW de National Instruments , conectar sus aplicaciones con los servicios web ofrecidos por ISA.

128

Esta arquitectura no utiliza los servicios, ni soporta los estndares que ofrecen los LMS. As, todos los laboratorios conectados a esta arquitectura que quieran ofrecer servicios de comunicacin, de contenido, de evaluacin etc. Deben crearlos (figura 51).

5.3

Tipos de experimentos definidos en iLab

Uno de los aspectos claves de esta arquitectura ISA, es el concepto de experimento. As, dependiendo del tipo de experimento, la arquitectura sufre modificaciones y los servicios web a utilizar tambin varan. El proyecto iLab clasifica los experimentos en tres categoras o grupos [Harward, 2004]: 1. Experimentos por Lotes o Batch. El estudiante, antes que empiece el experimento, especifica todos los parmetros que gobiernan la ejecucin de este. 2. Experimentos con sensores. El estudiante, normalmente, no puede especificar ningn parmetro de un sensor. Simplemente monitoriza y analiza el flujo de datos que le llega. 3. Experimentos interactivos. El estudiante configura una serie de parmetros, inicia el experimento y luego monitoriza su desarrollo, pudiendo cambiar los parmetros de control si es necesario. A continuacin se van a describir ms detalladamente la arquitectura para experimentos por lotes y la arquitectura para experimentos interactivos (incluye los experimentos con sensores).

129

Arquitectura para experimentos por lotes o batch La primera fase del proyecto iLab fue desarrollar una arquitectura que permitiera compartir y soportar experimentos por lotes o batch. Esta arquitectura se asemeja a la arquitectura de negocio web basada en tres capas (figura 73):

La primera capa es la aplicacin del cliente o estudiante que ejecuta un applet o una aplicacin instalable en su PC.

La capa intermedia, llamada servicio Broker, proporciona los servicios comunes. Este, es respaldado por una base de datos relacional estndar (SQL Server u Oracle). El cliente o estudiante se comunica con el servicio y este es el encargado de enviar las especificaciones del experimento de usuario a la tercera capa. Es importante indicar que a diferencia de una arquitectura web basada en tres capas, en esta arquitectura cada universidad que implementa la arquitectura ISA tiene su propio servicio Broker.

La tercera capa es el servidor del laboratorio. Es el encargado de ejecutar el experimento especificado por el estudiante y de notificar al servicio Broker que los datos de la ejecucin ya estn disponibles.

Servicio Broker

Internet Dispositivos del Laboratorio Servidor del Laboratorio

Internet / Intranet

Cliente o Estudiante

Base de datos

Cliente o Estudiante

Figura 73.

Arquitectura de experimentos por lotes o batch [Hardward, 2004].

A continuacin se vern las llamadas y respuestas que ocurren cuando un cliente o usuario desea ejecutar un experimento por lotes (figura 74):

130

1. El estudiante inicia la sesin. Para ello, se autentica en el servicio Broker usando una conexin segura (SSL). El servicio brker implementa un esquema de autenticacin de nombre y usuario. 2. El servicio Broker responde al estudiante, mostrndole una lista de los grupos o clases en las que este est registrado. 3. El estudiante selecciona una de las clases mostradas.

Estudiante (Navegador Web)

Servicio Broker (Aplicacin Web)

Servidor del Laboratorio

1. Autenticacin sobre SSL 2. Listado de clases del alumno 3. Elegir clase para sesin 4. Listado de experimentos disponibles 5. Elegir experimento 6. Lanzar cliente del laboratorio

Usando el cliente del laboratorio y servicios Web

Usando servicios Web

Usando servicios Web

7. Submit (experimentSpecification) 8. Submit (experimentSpecification) 9. SubmissionReport 10. ClientSubmissionReport (experimentID) Ejecucin del Experimento 11. Notify(experimentID) 12. RetrieveResult (experimentID) 13. ResultReport 14. RetrieveResult (experimentID)

15. ResultReport

Figura 74.

Diagrama de secuencia de la ejecucin de un experimento por lotes.

131

4. El servicio Broker muestra todos los experimentos disponibles para esa clase. 5. El estudiante selecciona uno de los experimentos disponibles. 6. El servicio Broker lanza el experimento. Ejemplos: a. Un applet de java que es lanzado mediante una redireccin a una pgina con una etiqueta APPLET embebido. b. Una pgina ASP lanzada mediante una simple redireccin de la pgina del cliente. 7. El estudiante edita las especificaciones del experimento que quiere ejecutar. Cuando esto est hecho, se invoca el servicio Web submit() que est en el servicio Broker. Submit() Recibe un texto codificado en la versin de la especificacin del experimento como un argumento. El servicio Broker no se para a entender dicha especificacin. 8. El servicio Broker almacena una copia de la especificacin del experimento y reenvia la llamada submit() al servidor del laboratorio. 9. El servidor del laboratorio retorna inmediatamente un informe del envo. Este, incluye cualquier mensaje de error producido por una mala especificacin del experimento. 10. El servicio Broker reenvia dicho informe, junto con un identificador de experimento, al cliente del laboratorio. 11. Una vez que el servidor del laboratorio ejecuta el experimento. Este, llama al servicio Web Notify() que se encuentra en el servicio Broker.

132

Notify() indica que los resultados del experimento estn disponibles. 12. El servicio Broker recupera los resultados del servidor de laboratorio usando el servicio Web RetrieveResult(). 13. El servidor del laboratorio enva los resultados y cualquier mensaje de error al servicio Broker. El servicio Broker almacena los resultados, pero no puede interpretar dichos resultados. 14. El cliente, puede solicitar los resultados almacenados en cach del servicio Broker mediante el servicio Web llamado RetrieveResult(). Es importante que el cliente no necesita estar conectado mientras el experimento se ejecuta. 15. El servicio Broker devuelve los resultados y cualquier mensaje de error. Normalmente los experimentos por lotes o batch son atendidos mediante un sistema de colas. Ya que su duracin suele oscilar entre 10 y 100 segundos de duracin. Arquitectura para experimentos interactivos Como ya se ha comentado, en un experimento interactivo el estudiante configura una serie de parmetros, inicia el experimento y luego monitoriza su desarrollo, pudiendo cambiar los parmetros de control si es necesario. Por este motivo, en algunos momentos, ser necesario que el estudiante y el servidor de laboratorio puedan enviarse y recibir datos directamente (sin necesidad del servicio Broker), evitando esperas innecesarias (figura 75).

133

Experimentos por lotes o Batch

Experimentos Interactivos

No hay comunicacin directa

comunicacin directa

Servidor de laboratorio

Cliente de laboratorio

Servidor de laboratorio

Cliente de laboratorio

Servicio Broker

Servicio Broker

Figura 75.

Comunicaciones necesarias en los experimentos por lotes e interactivos.

As, la arquitectura ISA de los experimentos interactivos (figura 76) variar notablemente con respecto a la utilizada en los experimentos por lotes.

Lado del laboratorio

Servidor de laboratorio

Servicio de almacenamiento de experimentos Cliente de laboratorio 1

Servicio Broker Servicio Broker Cliente de laboratorio N

Servicio de planificacin del lado del cliente

Servicio de planificacin del lado del laboratorio

Lado del Cliente

Figura 76.

Arquitectura de experimentos interactivos [Hardison, 2008].

A continuacin se describir cada uno de los elementos que lo forman:

134

1. Servicio de almacenamiento de experimentos. En los experimentos por lotes el almacenamiento de los experimentos del estudiante descansaba en el servicio Broker. Esto era debido a que toda la informacin pasaba por el servicio Broker. Esto en los experimentos interactivos no es posible, ya que el servicio Broker establecer una relacin entre el estudiante que utiliza el cliente del laboratorio y el servidor del laboratorio. Y una vez establecida dicha relacin, el cliente del laboratorio y el servidor del laboratorio podrn hablar de forma directa. Por este motivo, es necesario crear un nuevo servicio independiente que almacene los datos de los experimentos y que pueda ser accedido por el servicio Broker, el cliente del laboratorio y el servidor del laboratorio. Este servicio recibe el nombre de Servicio de almacenamiento de experimentos o ESS. Entre sus caractersticas estn: o Es implementado como un sistema independiente o Permite a los servicios Brokers, clientes de laboratorio y servidores de laboratorio almacenar datos de los experimentos. o Los registros del ESS consisten en datos del experimento: datos binarios (imgenes, video o audio) y datos numricos y de texto basados en XML. No contiene informacin administrativa. o Requiere de un alto ancho de banda para recoger toda la informacin de la ejecucin del experimento. 2. Servicio de planificacin. Mientras que los experimentos batch normalmente son gestionados mediante un sistema de colas, ya que su duracin es muy corta, entre 10 y 100 segundos, los experimentos interactivos suelen durar mucho ms, y durante ese tiempo el cliente del laboratorio tiene el control del

135

hardware. Por todo esto, es necesario gestionar un calendario que permita a los estudiantes reservar y utilizar el laboratorio para realizar sus experimentos. El encargado de realizar todo esto es el servicio de planificacin que consta de dos sistemas basados en servicios Web: 1. El servicio de planificacin del lado del cliente o USS 2. Servicio de planificacin del lado del laboratorio o LSS Ambos sistemas funcionan conjuntamente. As cuando un usuario se autentica y quiere reservar un tiempo en el laboratorio, el USS le muestra un conjunto de posibles bloques de tiempo que le ha comunicado el LSS. Una vez seleccionado un bloque en el USS, este lo almacena y se lo notifica al LSS para que lo borre de bloques disponibles. Hay casos en los que las reservas de los estudiantes pueden ser canceladas por el profesor o tutor. El responsable de notificar las cancelaciones es el USS 3. El servicio Broker y el Ticketing. El servicio Broker es responsable de la autenticacin del usuario y el uso autorizado de los recursos del servidor del laboratorio. En los casos en los que el servicio Broker de lado de usuario y el servidor de laboratorio pertenecen a distintas instituciones, dicho servicio deber manejar adecuadamente las credenciales del usuario. Por todo ello un nico sistema de autenticacin tiene que ser construido. Este sistema fue implementado a travs de un modelo de servicios Web llamado Ticketing, que permite que los servicios de la arquitectura ISA, por si mismos o en nombre de otros servicios, puedan acceder a los recursos a travs de tickets. A continuacin se va a ver un ejemplo de este sistema: 1. El estudiante introduce su nombre de usuario y su password.

136

2. Una vez que se autentica y es autorizado para llevar a cabo un experimento. Se crean dos tickets que permiten la ejecucin del experimento y el almacenamiento de datos, y un cupn que representa ambos tickets. 3. El cupn es enviado a la instancia del cliente del laboratorio. 4. Para conectarse al servidor del laboratorio y comenzar el experimento. El cliente del laboratorio enva el cupn al servidor del laboratorio, el cul recupera el ticket de ejecucin del experimento del servicio de expedicin del Broker. 5. Si el ticket que devuelve es vlido entonces el cliente es autorizado a realizar el experimento (en un espacio de tiempo). 6. Cuando es necesario grabar los datos del experimento, el cupn es enviado al ESS, que recupera el ticket de almacenamiento de datos. Es importante mencionar, que cada ticket es recuperado una sola vez por sesin.

5.4

Ejemplo de utilizacin de iLab para experimentos batch

En este apartado se va a describir un ejemplo de acceso y manejo de un laboratorio dentro de iLab: 1. El usuario debe autenticarse, para ello introduce su nombre de usuario y contrasea (figura 77).

137

Figura 77.

Acceso a iLab.

2. Una vez autenticado en el sistema, iLab procede a la autorizacin. En este caso, solo se mostraran los laboratorios a los que un invitado puede acceder (figura 78).

Figura 78.

Lista de laboratorios disponibles para los usuarios invitados en iLab.

138

3. El estudiante selecciona el laboratorio que desea lanzar. Aparecer una pgina con el nombre del laboratorio, una descripcin de este, un enlace a la documentacin del laboratorio y dos botones: uno para lanzar el laboratorio y otro para mostrar la cmara Web que muestra el dispositivo fsico (figura 79).

Figura 79.

Pgina que aparece al seleccionar un laboratorio.

4. Se lanza el laboratorio, el cliente del laboratorio (en este caso un Applet de java) y la cmara Web. Y se realiza el experimento (figura 80). En este caso los resultados se muestran en una grfica.

Figura 80.

Cliente del laboratorio y cmara Web.

139

5.5

Resumen

El proyecto iLab surgi con la idea de reutilizar laboratorios de diferentes organizaciones. Para ello ha definido una arquitectura que vara en funcin del tipo de experimento (batch o interactivo). La arquitectura est implementada en servicios Web que utilizan el protocolo SOAP para el intercambio de informacin. Aunque est arquitectura permite la reutilizacin de laboratorios. No utiliza servicios colaborativos, estndares e-learning como SCORM, IMS-QTI, etc. Y en el caso de quererlos utilizar cada laboratorio debera implementarlos (figura 51). En el siguiente captulo presentaremos una arquitectura que pretende dar una solucin nica al aprendizaje terico y prctico. De tal forma que se puedan reutilizar los servicios y estndares e-learning ofrecidos por un sistema de gestin de aprendizaje y la realizacin de prcticas de laboratorios.

140

CAPTULO 6. DISEO MIDDLEWARE PARA LABORATORIOS

DE LA

UNA ARQUITECTURA INTEGRACIN DE LMS

O Y

6.1

Problemtica actual y necesidad de una nueva arquitectura

Como se ha visto en los captulos anteriores existen dos soluciones que permiten: 1. Gestionar y organizar contenido terico para el estudiante. Ofrecen herramientas y servicios de comunicacin, tanto sncrona como asncrona, de autenticacin, de evaluacin, etc. Adems, de estndares e-learning para la reutilizacin de contenido, evaluaciones, etc. Esta solucin, como ya se ha comentado, recibe el nombre de sistema de gestin del aprendizaje o LMS. 2. Permitir que los estudiantes obtengan las habilidades necesarias para enfrentarse a su vida laboral sin problemas (manejo de dispositivos, solventar e interpretar posibles problemas prcticos con los que se puede encontrar, etc.). Esta solucin, como ya se ha comentado, recibe el nombre laboratorios software, web, remotos o basados en la arquitectura iLab. Actualmente ambas soluciones son independientes, por lo que nos encontramos con los siguientes problemas:

El usuario debe acceder a ambos sistemas utilizando los servicios de autenticacin de los laboratorios y de los sistemas de aprendizaje que utilice. Imagine un estudiante que trabaja con dotLRN y necesita hacer prcticas en tres laboratorios de universidades diferentes. En este caso el estudiante tendra que acceder a los servicios de autenticacin de cada sistema, probablemente con una clave y contrasea distinta para cada sistema.

141

Los estudiantes no tienen una nica solucin con la que trabajar. Es decir, para estudiar y evaluar sus progresos disponen del sistema de gestin de aprendizaje y para realizar sus prcticas los diferentes laboratorios en diferentes sistemas.

Los laboratorios no reutilizan los servicios y posibilidades que le ofrecen los LMS (servicios colaborativos, estndares e-learning, etc.) sino que crean sus propios servicios, en ocasiones, estos no son reutilizables por otros laboratorios. Algunos ejemplos: o Dificultad en reutilizar servicios de comunicacin sncrona y asncrona, debido a diferencias en su arquitectura. o Dificultad en compartir elementos tericos de forma sencilla. Mientras que usando estndares como el paquete IMS o SCORM, diferentes universidades podra utilizar esos elementos tericos de forma sencilla. o Dificultad de reutilizar elementos de evaluacin o autoevaluacin. o Utilizar herramientas de seguimiento de usuario que proporcionan los LMS. En caso de quererlas utilizar cada laboratorio debe

implementarlas de forma separada.

Los sistemas de gestin de aprendizaje no dispone de un mdulo o paquete que permita el uso de laboratorios. Por tanto lo programado para un LMS de una universidad no puede ser reutilizado de forma sencilla en otra.

Reutilizar laboratorios en diferentes cursos. Como se ha dicho el proyecto iLab permite reutilizar diferentes laboratorios en diferentes universidades, pero no incluye elementos como estndares de contenido, evaluacin, chats, foros, etc.

142

Estos y otros problemas estn actualmente sucediendo (figura 81). En este captulo se plantea una arquitectura que permita la creacin y utilizacin de ambas soluciones en una sola (figura 82), permitiendo:

Autenticacin

Herramientas de Grupo

Interfaz de Usuario

Autenticacin Herramientas de Evaluacin Contenidos (No SCORM) Laboratorio

Grupos y Gestin de Perfiles

Herramientas de Evaluacin (IMS-QTI) LMS

Herramientas de Comunicacin

Contenidos (SCORM, IMS)

Herramientas de Comunicacin

Servicio de reservas

Grupos y Gestin de Perfiles

Base de Datos

Seguridad

Gestin de Logs de Experimentos

Logs

Figura 81.

Servicios proporcionados por los LMS y laboratorios.

Utilizacin del servicio de autenticacin del LMS y transparencia de acceso a los laboratorios web y remotos. Soluciones single sig-on.

Utilizacin de los servicios de los sistemas de gestin de aprendizaje, como: gestin de contenido, portfolios, herramientas colaborativas, etc. Para los diferentes laboratorios, independientemente de su arquitectura.

Utilizacin de estndares educativos: paquetes IMS, IMS-QTI, SCORM, etc.

Comunicar los laboratorios y LMS de una forma estndar, utilizando una API comn. Por supuesto, comunicar laboratorios aislados en Internet y comunicar los laboratorios proporcionados con el proyecto iLab del MIT.

143

Sacar de la implementacin de los laboratorios, servicios como el servicio de reservas. Y que este servicio sea general para todos los LMS, laboratorios y usuarios.

Autenticacin

Herramientas de Grupo
Herramientas de Evaluacin (IMS-QTI) LMS Servicio de reservas

Interfaz de Usuario

Autenticacin bsica

Grupos y Gestin de Perfiles

Laboratorio

Contenidos (SCORM, IMS)

Herramientas de Comunicacin

Base de Datos

Seguridad

Gestin de Logs de Experimentos

Logs

Figura 82.

Se libera de servicios al laboratorio y se reutilizan los del LMS.

Actualmente se ha creado un paquete para dotLRN y Moodle que permite conectar diferentes tipos de laboratorios (Web y remotos) dentro de los cursos ofrecidos por ambos LMS. Esto permite:

Utilizar la autenticacin y autorizacin de los LMS para mostrar los laboratorios a los que los estudiantes tienen acceso dentro de un curso.

Reutilizar estos paquetes creados en cualquier institucin que tenga Moodle o dotLRN.

Hacer transparente al usuario el acceso al laboratorio. Una nica solucin que contenga ambos aprendizajes.

144

Utilizar los servicios de comunicacin, herramientas de evaluacin, etc. Ofrecidas por el LMS.

6.2

Diseo de la arquitectura

En el apartado anterior se ha visto la necesidad de crear una arquitectura capaz de unir ambas soluciones en una sola. En esta arquitectura estarn implicadas cuatro capas: Capa de usuario, LMS, bus de servicios y servidor del laboratorio. A continuacin se describir cada una de ellas (figura 83).

Laboratorio Software

Internet Controlador

? ? Instrumentos

Estudiante Internet

LMS Estudiante 1. Navegador Web 2. Applet de Java o aplicacin Web del laboratorio

M I D D L E W A R E

Laboratorio Software Internet Internet ? ? Instrumentos Controlador

Servidor Broker Base de datos

Gestin de Conocimiento: - Servicios de administracin - Paquetes de contenido - Herramientas de comunicacin sncronas y asncronas - Herramientas colaborativas - Logs y resultados de los experimentos - Evaluacin Estndars e-learning (LOM, SCORM, IMS, QTI, etc.)

Figura 83.

Middleware de Integracin.

6.2.1

Capa de Usuario

En esta capa, el usuario solamente necesita un navegador web que muestre las aplicaciones web con las que se va a trabajar. Dependiendo de la aplicacin, el usuario deber instalar algn plug-in en el navegador.

145

Es importante indicar que dependiendo del perfil de usuario (miembro, administrador del curso, administrador del LMS), este podr realizar diferentes acciones sobre las herramientas y servicios del LMS y sobre los laboratorios integrados.

Administrador del LMS. Es el encargado de administrar el sistema de gestin de aprendizaje. En el caso de los laboratorios. El administrador del .LRN deber realizar un conjunto de operaciones que incluyan toda la informacin necesaria para que el resto de usuarios puedan utilizarlos (figura 84). Por tanto, deber:

Crear curso extends extends Gestionar laboratorios LMS

Gestin laboratorios

Administrador del LMS

uses extends extends

uses

Gestionar tipos laboratorio

Gestionar acceso laboratorio

Figura 84.

Caso de uso del administrador de .LRN para los laboratorios.

o Crear los cursos que se van a llevar a cabo dentro del LMS. Cada curso deber poder obtener un listado de los laboratorios y utilizarlos. o Gestionar los tipos de laboratorios. Es decir establecer una categora o clasificacin de estos. Por ejemplo laboratorios web y laboratorios remotos. o Gestionar el acceso a los laboratorios. Es necesario gestionar que tipos de acceso a los laboratorios estn incluidos en el LMS. Ejemplos: Acceder solamente a travs de una URL. Acceso utilizando nombre de usuario y contrasea.

146

Acceder mediante algn certificado electrnico.

o Gestionar los laboratorios implica poder aadir, editar y modificar los laboratorios que van a ser ofrecidos por el LMS. A parte de informacin del laboratorio: nombre, URL, etc. Es necesario indicar el tipo de laboratorio que es y el tipo de acceso que tiene.

Administrador del curso. Es el encargado de gestionar el curso dentro del LMS (figura 85). Por tanto deber poder realizar las siguientes acciones: o Gestionar los servicios y herramientas del LMS. Es decir activar, desactivar o editar los servicios y herramientas del curso. Por ejemplo activar o desactivar la herramienta de foros. o Gestionar los laboratorios. Establecer que laboratorios pueden ser accedidos a travs del curso o en que fechas.

extends

gestionar servicios y herramientas del curso

Gestionar laboratorios-curso

extends Gestin laboratorios en el curso extends

Administrador del curso

Utilizar laboratorios

Figura 85.

Caso de uso del administrador del curso para los laboratorios.

Miembro del curso. Es el encargado de utilizar las herramientas y servicios ofrecidos por el curso (figura 86).

147

Usar servicios y herramientas LMS

extends

Utilizar laboratorios

Miembro de un curso extends extends

Estudiante

Profesor

Figura 86.

Caso de uso de un miembro de un curso en el LMS.

6.2.2

Capa del LMS

El LMS es el encargado de atender las peticiones de usuario y de mostrar el contenido de aprendizaje de una forma ordenada y controlada. Para realizar dichas funciones, se defini una arquitectura web con los siguientes elementos:

Un sistema gestor de base de datos. Contiene la informacin (usuarios, cursos, evaluaciones, copias de seguridad de los cursos, etc.) que da soporte a las herramientas y servicios del LMS. En la figura 87 se puede ver una parte del modelo de base de datos utilizado por la herramienta chat y su relacin con los usuarios del LMS.
Usuario

Chat

Figura 87.

Modelo entidad-relacin de los usuarios y los chats del LMS.

148

Los mdulos o paquetes que representan la lgica de cada uno de los servicios y herramientas del LMS. Como se vio en captulos anteriores, dependiendo del LMS, los paquetes y mdulos tendrn estructuras de archivos diferentes y se programarn en lenguajes diferentes (figura 32 y 40).

Un servidor web, encargado de mostrar al usuario las pginas Web necesarias para mostrar los contenidos y utilizar las herramientas y servicios ofrecidos por el LMS. En esta capa se deber crear un mdulo o paquete que permita gestionar y utilizar los laboratorios web remotos dentro del LMS y un conjunto de servicios web que ofrezcan una API de conexin con otros sistemas (figura 88).

Lado del LMS

Nuevas aplicaciones y servicios (creacin del modelo de datos, lgica de la aplicacin e interfaz de usuario)

Pginas Web dinmicas o estticas Servicios Web

Aplicaciones y Servicios

Base de datos

Figura 88.

Creacin de un paquete en el LMS y de los servicios Web necesarios.

1. Creacin de un mdulo o paquete del LMS. Este, deber estar compuesto por: a. Un conjunto de tablas y relaciones que den soporte a la lgica del mdulo o paquete. Ser posible actualizar o modificar dicho modelo de datos (figura 89). En un principio se ha pensado en las siguientes tablas:

149

Servidor Web

1
tipo_acceso_laboratorio

PK

id nombre

tipo_laboratorio laboratorio PK id descripcin nombre id_acceso id_tipo url

PK

id

n n
experimento PK id fecha id_curso id_lab id_alumno id_sesion

Figura 89.

Modelo entidad relacin, bsico, del paquete.

i. Tabla tipo_laboratorio. Esta tabla simplemente describe si un laboratorio es web, remoto, etc. ii. Un conjunto de tablas (tipo_acceso_laboratorio, acceso_login) para indicar el tipo de acceso al laboratorio: usuario-contrasea, acceso sin autenticacin, etc. Actualmente estas tablas son necesarias ya que los mtodos para accede a cada uno de los laboratorios de las organizaciones es muy variado. En un futuro estas tablas deberan desaparecer y utilizar un mtodo de single sign-on. La mayora de los LMS ya soportan LDAP, Kerberos, etc. iii. Tabla laboratorio. Incluye los datos para describir el laboratorio. Algunos de los campos que debe contener es URL de laboratorio y claves ajenas de la tabla tipo_laboratorio y tipo_acceso_laboratorio iv. Tabla Experimento. Donde se almacene informacin sobre la fecha en que se realizo el experimento, la sesin del

150

experimento y los resultados que se han obtenido al realizar dicho experimento dentro de un curso. b. La lgica de negocio del paquete. En nuestro caso deber ser capaz de aadir laboratorios a un curso, borrarlos, editarlos y dar acceso, de una forma transparente, a los laboratorios aadidos (URL con id de sesin, URL con usuarios y contrasea, envo de informacin usando un servicio Web, etc.). Es importante tener en cuenta que la estructura y el lenguaje de programacin de los paquetes y mdulos depende del LMS. Adems de la lgica de negocio es necesario disear las interfaces de usuario (administrador del LMS, administrador del curso, estudiante, profesor) que sern mostradas por el servidor Web. Los mdulos y paquetes son reutilizables. Es decir, si nosotros diseamos e implementamos un mdulo en Moodle. Este podr ser instalado y utilizado en cualquier organizacin que tenga instalado Moodle. 2. Crear los servicios web (por ejemplo, SOAP o REST) que van a ser consumidos por el servicio brker o por el servidor de laboratorio. Estos servicios deben proporcionar una API comn para todos los laboratorios. Algunos de los servicios proporcionados son:

Confirmar Autorizacin. El sistema deber comprobar que quien enva informacin tiene autorizacin para ello.

Almacenar

experimento.

Donde

se

recibe

la

informacin

del

experimento realizada por un estudiante y la forma de mostrar dicho experimento.

151

6.2.3

El servidor del laboratorio

Conecta con el hardware del laboratorio y gestiona la ejecucin del experimento enviado por el usuario. Deber contener los servicios web para comunicarse con el LMS. En el caso del servicio broker del MIT, este tambin deber contener los servicios necesarios para que el LMS pueda comunicarse con l. Actualmente se esta trabajando con el MIT en este aspecto. El servidor del laboratorio almacenar informacin como Identificador del LMS, id de sesin del experimento, id_curso y estudiante. De tal forma, que el LMS pueda recuperar la informacin de los experimentos realizados. Tambin se definir las credenciales necesarias para autenticar cualquier LMS y darle acceso a los posibles experimentos que puede realizar sobre l.

6.2.4

Middleware de comunicacin

Es necesario intercambiar entre ambas capas informacin de autenticacin y de autorizacin, envo de experimento, recepcin de experimentos, etc. Todo ello debe realizarse a travs de Internet. Actualmente, la solucin ms utilizada son los servicios Web (figura 90). Estos ofrecen:

Servicio

Consumido Va Internet

Aplicacin Cliente

INTERNET Ofrecido como

Interfaz Capacidad
usuario

Figura 90.

Patrn servicio-consumidor [Governor, 2009].

152

Interoperabilidad entre aplicaciones independientemente del lenguaje utilizado o de la plataforma en que se ejecutan.

Utilizan estndares como XML, SOAP, WDSL o UDDI.

Los servicios web se apoyan en el protocolo HTTP y por tanto pueden acceder a otros sistemas de otras organizaciones sin quedarse atrapados en los filtros de seguridad de los firewalls. Arquitectura de Servicios Web: SOAP y REST Actualmente dos de las arquitecturas de servicios Web ms extendidas son REST y SOAP. A continuacin describiremos brevemente cada una de ellas.

Servicios Web con SOAP. SOAP es un protocolo basado en XML cuyo objetivo es intercambiar informacin estructurada (figura 91) en un entorno distribuido y descentralizado [W3-SOAP, 2010]. SOAP es soportado por un gran nmero de protocolos como HTTP o SMTP. Como cualquier aplicacin cliente/servidor, el cliente enviar una peticin SOAP con la informacin necesaria para que el servicio pueda atenderla. Una vez atendida, el servicio mandar la respuesta SOAP al cliente (figura 92) SOAP no suele trabajar de forma individual sino que tiene asociados un grupo de estndares que facilitan la identificacin y utilizacin de los servicios. Estos estndares son: o WSDL es un lenguaje basado en XML para describir los servicios web disponibles. Este fichero permite a los programadores de la aplicacin cliente, identificar los mtodos disponibles dentro del servicio y los parmetros de entrada y de salida de dichos mtodos.

153

o UDDI es una especificacin tcnica para describir, descubrir e integrar servicios web.

<SOAP-ENV:Envelope <env:Header>
(Opcional)

<env:Body> (Requerido)

Figura 91.

Estructura del mensaje SOAP.

HTTP

Peticin SOAP

Cliente SOAP

Servicio SOAP

Respuesta SOAP

HTTP

Figura 92.

Intercambio de mensajes SOAP a travs de HTTP.

Servicios Web REST [Fielding, 2000]. REST es una arquitectura enfocada a un acceder a los recursos de un manara sencilla y sin estado. Sin estado, implica que no se almacena (ni en el cliente, ni el servidor) el estado de la comunicacin. RESTfull HTTP utiliza los cuatro mtodos fundamentales de HTTP GET, PUT, POST y DELETE. Estos mtodos permiten realizar las operaciones de recuperar, crear, actualizar y borrar recursos en el servidor. Estos recursos son ofrecidos en Internet y se identifican mediante un identificador nico de recurso (URI) o una URL para referenciar al recurso (figura 93). Aunque confa en la idea de que las peticiones y las respuestas de la arquitectura REST son entendibles por el ser humano, existe una

154

especificacin para describir los servicios. Esta especificacin recibe el nombre de lenguaje de descripcin de aplicaciones Web o WADL.

GET /libro/?ISBN=12

Cliente Respuesta (XML, JSON, etc.)

Servicio Web

getLibro(12)

Figura 93.

Ejemplo de llamada a un servicio Web y respuesta.

Dependiendo de las necesidades, se utilizar REST o SOAP. As SOAP permite interacciones seguras y confiables. Mientras que REST permite interacciones ms ligeras de carga y sencillas de utilizar. En la tabla 6.1 se puede ver una comparativa de ambas arquitecturas:

Tabla 6.1. Comparativa Arquitectura REST y SOAP.

Aspectos

SOAP

REST

Tecnolgicos

Enfocado en el diseo de aplicaciones integradas. (orquestacin, composicin mediante procesos de negocio)

Enfocado en escalabilidad y desarrollo a gran escala de sistemas hipermedia distribuidos (Mashups, URI)

Protocolos

Varios protocolos (HTTP, SMTP,)

Solo HTTP

Descripcin del Servicio Especificaciones WSDL 1.1. y 2.0

Confa en entregar documentos claramente entendibles. Aun as, puede utilizar WADL

Seguridad

WS-Security

Seguridad sobre HTTP

Herramientas

Existen un gran nmero de herramientas No es necesario herramientas para crear estos servicios

155

Arquitectura Orientada a Servicios (SOA) SOA ms que una arquitectura es una aproximacin o idea de pensar que lidera ciertas decisiones a la hora de disear una arquitectura software [Josuttis, 2007] [Davis, 2009] [Erl, 2008] [OASIS-SOA, 2009]. As, los conceptos tcnicos de los que habla SOA [Rosen, 2008] [Hewitt, 2009] [Juric, 2007] son:

Servicios. SOA define una representacin de alguna funcionalidad de negocio. Aunque estos servicios internamente son tcnicos, deben disponer de una interfaz que sea comprensible por cualquier persona.

Interoperabilidad. Cuando se trabaja con sistemas heterogneos el primer objetivo es conectar estos sistemas fcilmente. SOA es la base para implementar servicios a travs de mltiples sistemas distribuidos.

Dbilmente acoplado. Con el objetivo de conseguir: o Flexibilidad. o Escalabilidad. o Tolerancia a fallos. SOA no est ligada a una tecnologa en concreto, pero si se utiliza la tecnologas existentes para desarrollarla. Una realizacin de una arquitectura SOA, es la unin de las especificaciones SOAP, WSDL y UDDI. Estas, en conjunto, permiten que sistemas heterogneos puedan buscar, encontrar y utilizar el servicio que necesitan independientemente del sistema que lo ofrece y el cliente que lo consume (figura 94). En otras ocasiones se puede utilizar REST y WADL para desarrollarla. A parte del registro de servicios, la bsqueda y utilizacin de estos. SOA introduce el concepto de orquestacin o proceso de negocio. Uno de los lenguajes ms utilizados

156

actualmente es el lenguaje de ejecucin de procesos de negocios con servicios Web o WS-BPEL (es un XML). En la figura 95 podemos ver un ejemplo de flujo de trabajo creado con una herramienta que genera WS-BPEL.

Repositorio UDDI

UDDI

Pu

ar

bl

sc

ic ar

Bu

SD W

W SD

Consumidor del Servicio

SOAP

Proveedor del Servicio

Figura 94.

Arquitectura SOA utilizando SOAP, WSDL y UDDI [ITProfessionals, 2009].

Figura 95.

Ejemplo de proceso de negocio [SOAHowto, 2009].

Existen un gran nmero de herramientas que permiten utilizar las diferentes tecnologas para crear una arquitectura SOA. Estas pueden ser:

157

Herramientas propietarias como SOA Suite de Oracle.

Herramientas de cdigo abierto: o Procesos de Negocio / BPM : jBPM, Intalio, Bonita Workflow o Servidores de Aplicaciones : Jboss o Frameworks para Servicios Web : Metro, Axis o Entornos de desarrollo : Eclipse, Netbeans SOA permite la reutilizacin de servicios, eso s, tanto el cliente como el servicio deben utilizar la misma arquitectura (REST, SOAP) y dentro de ellos ser capaces de entender tanto las peticiones como las respuestas a esas peticiones. Por tanto los sistemas deberan seguir la misma arquitectura de servicios, la misma estructura de mensaje, etc. Para evitar esto, y proporcionar nuevas caractersticas: enrutamiento y transformacin. As, en algunos casos SOA se apoya en los enterprise service bus o ESB. Enterprise Service Bus (ESB) Como se acaba de comentar dentro de internet existen un gran nmero de sistemas, con diferentes arquitecturas e implementaciones. Para comunicar esta gran variedad de sistemas y arquitecturas aparecieron los ESB [Chappell, 2004]. As, Adems de las caractersticas ofrecidas por SOA, ESB aporta las siguientes tareas:

Transformacin de datos [Williams, 2009]. Para permitir que los sistemas sean capaces de entenderse, an cuando los tipos de datos son diferentes para cada uno.

Enrutamiento. Enviar la peticin al servicio correcto o a la mquina que en ese momento est menos ocupada.

158

Manejo de versiones. Para resolver de forma automtica posibles cambios en los servicios publicados en el ESB.

Seguridad. Establecer mecanismos de seguridad para las peticiones y respuestas.

Monitorizacin del flujo de informacin que viaja por el ESB. Por supuesto tambin tiene desventajas como: una mayor latencia en la informacin o una administracin adicional. Aun as, si el ESB est bien diseado, esta latencia no afectara a los experimentos interactivos, ya que hasta que estos no acabarn no se recuperara la informacin del servidor de laboratorio. En el caso de la comunicacin de los LMS con los laboratorios y con otros sistemas o servicios como el de reserva de hora para los experimentos. Se ha decidido utilizar este middleware. 1. La mayora de los LMS estn empezando a dar soporte tanto a la arquitectura SOA como REST. 2. Los servidores de laboratorios, dependiendo del programador, tendrn implementada una de las arquitecturas de servicios web u otra forma de comunicacin. 3. Permite la coreografa de servicios. Imaginemos que un experimento pudiera trabajar con dos o ms tipos de laboratorios. 4. Permite incluir control de versiones y monitorizacin. 5. Los ESB de diferentes universidades u organizaciones ofrecen una pasarela externa para comunicarse entre ellos.

159

En este caso, debido a la dificultad de universalizar (una nica arquitectura) los sistemas y servicios de LMS y los laboratorios nos hemos decidido por esta solucin que permite transformar datos y comunicar sistemas con diferentes arquitecturas (figura 96). Por ejemplo un cliente REST con un servicio SOAP o viceversa.

WS REST
Co m res pro erv bar a

Servicio de reserva

Adaptador

2.

WS REST

Servidor Laboratorio 1

LMS Cliente REST

1. Peticin del servicio acceso laboratorio 2

4. Acceso ok. Entonces pedir acceso

3. O k

Adaptador

6.

Inf o

rm a

E S B

Servidor WS Laboratorio SOAP 2

ci

Adaptador

nd

ea

5. Informacin de acceso

cce

so

Figura 96.

Utilizacin de un ESB, enrutamiento, transformacin y coreografa de servicios.

A continuacin, indicaremos algunos de los flujos de informacin necesarios para intercambiar informacin entre el LMS, el servidor de laboratorio y otros sistemas o servicios: 1. Fase de Autenticacin. Es necesario que el Servidor del laboratorio reciba del LMS las credenciales necesarias para permitir al usuario del curso acceder al laboratorio. En los casos que: a. Exista ms de un laboratorio similar, el ESB debera ser capaz de darle acceso al laboratorio mas desocupado. i. Si el experimento es por lotes, la cola ms vaca.

160

ii. si el experimento es interactivo deber comprobar el servicio de reserva. Segn est diseado actualmente el servicio brker. Esta fase se dividira en dos: a. Una fase de autenticacin donde se da al LMS el listado de los experimentos que puede utilizar. b. Una fase de autorizacin donde se le autoriza a un usuario del LMS a acceder al experimento del curso. Actualmente el servicio broker est en SOAP con lo cual si no se usar un ESB todos los LMS se veran obligados a realizar clientes SOAP. 2. Fase de recepcin del experimento. Donde: a. Se comprueban las credenciales del servidor de laboratorio que enva la informacin. b. Si ok, el LMS recibe el experimento del propio servidor o del servidor de almacenamiento de experimentos. Este es un claro ejemplo de orquestacin de servicios: primero compruebo credenciales y si es ok obtengo el resultado del experimento. 3. Informe de recepcin. El laboratorio debera recibir informacin del LMS confirmndole que el experimento ha llegado correctamente.

6.3

Resumen

En este captulo se ha indicado la necesidad de crear una arquitectura capaz de integrar los sistemas de gestin de aprendizaje o LMS con los laboratorios Web o remotos.

161

Para ello se ha definido una arquitectura capaz de integrar los diferentes sistemas y arquitecturas como un nico sistema, incluyendo: 1. Establecer las interfaz que permitan el manejo del las herramientas del LMS y de los laboratorios. Dependiendo del perfil se podrn realizar distintas operaciones. 2. Crear un paquete o mdulo en los LMS capaz de gestionar y dar acceso a los laboratorios web y remotos. Estos mdulos solo deben ser creados una vez. De tal forma que si es creado un paquete en dotLRN este podr ser reutilizado por cualquier organizacin que utilice dicho LMS. Lo mismo ocurre con otros LMS como Sakai, Moodle, Claroline, etc. 3. Permitir al usuario trabajar con los laboratorios de forma transparente e intercambiar informacin con el LMS. Al ser sistemas independientes y heterogneos es necesario buscar una arquitectura que permita integrarlos y proporcionar caractersticas tales como: enrutamiento, coreografa,

transformacin, etc. Por todo ello nosotros nos hemos decantado por los ESB, ya que ofrecen la posibilidad de utilizar un gran nmero de arquitecturas como una sola.

162

CAPTULO 7.

IMPLEMENTACIN Y DESARROLLOS

7.1

Introduccin

En este captulo se va a describir el desarrollo que se ha realizado de dicha arquitectura, creandose una serie de paquetes o mdulos para la gestin y acceso de laboratorios en dotLRN y Moodle. Adems se muestra la dificultad de crear un mdulo en sistemas de gestin de aprendizaje de iniciativa privada como WebCT. Y como es posible integrar de una forma suave estos laboratorios. Actualmente se est trabajando con el MIT en el middleware para comunicar los mdulos creados en el LMS con el server brker y con los laboratorios de las universidades de Deusto y Rosario para definir ms detalladamente los servicios de esta capa.

7.2

Creacin de un paquete de laboratorio en LMS de cdigo abierto

Se ha desarrollado un paquete de dotLRN y un mdulo de Moodle para gestionar los laboratorios dentro de cada uno de ellos y para aadirlos dentro de los cursos que ofrecen. A continuacin describiremos como se ha programado cada uno de ellos.

7.2.1

Desarrollo de un paquete para laboratorios virtuales y remotos en .LRN

Como se ha indicado en el captulo dedicado a los sistemas de gestin de aprendizaje, dotLRN es un paquete para la gestin de comunidades virtuales de aprendizaje e investigacin basado en OpenACS. Al ser software libre, permite conocer la arquitectura y programacin de todos y cada uno de sus componentes. En este

163

apartado se van a describir los pasos para aadir un nuevo paquete que se encargue de la gestin de laboratorios (figura 97)

Modulo de Aplicaciones
Administracin de Cursos (Calendario , Evaluacin, Seguimiento de usuarios ) Standards (IMS, SCORM) Collaboration (forums, chats) Contenidos (gestin de contenidos , rea de almacenamiento , etc.) Otros (e-commerce)

Entorno laboratorio

Servicios de Aplicaciones
(Repositorio de contenidos , Servicios Web, etc.)

Servicios de la plataforma
Desarrollo de software (gestin de paquetes , plantillas , etc.) Orientacin a Objetos Seguridad (Permisos OpenACS , restricciones de pgina , etc)

AOLserver (TCL) Base de datos (PostgreSQL, Oracle)

Sistemas operativos (Windows, Solaris, Linux,BSD)

Figura 97.

Arquitectura de dotLRN con el paquete entorno laboratorio.

Para explicar el desarrollo de este paquete es conveniente conocer mas detalladamente la arquitectura de dotLRN, ampliando lo explicado en el captulo 3. Por este motivo vamos a empezar describiendo la arquitectura y los elementos que la forman. Y posteriormente se describir el proceso realizado para crear el paquete de gestin de laboratorios: Arquitectura de OpenACS/dotLRN Uno de los aspectos claves a la hora de crear un paquete en dotLRN es su modelo de datos. Dicho modelo est orientado a objetos (figura 98) y es implementado en una base de datos relacional, como Oracle y PostgreSQL. Por tanto:

Las tablas servirn para definir las clases y contener los objetos.

164

Los procedimientos PL/SQL y PL/pgSQL servirn para definir los mtodos de las clases definidas en las tablas. La mayora de las aplicaciones y servicios necesitan extender este modelo para almacenar informacin adicional. Por ejemplo, el paquete entorno laboratorio v1 plantea un modelo de datos para la creacin y gestin de laboratorios virtuales y remotos (figura 99).

Figura 98.

Modelo de datos de dotLRN.

165

Figura 99.

Modelo de datos de paquete entorno laboratorio de dotLRN.

Cada paquete encapsula el modelo de datos, la librera de cdigo, la lgica de control, las pginas de administracin y de usuario. En OpenACS hay dos tipos de paquetes:

Aplicacin. Es un paquete con interfaz de usuario (foros, noticias, etc.). El paquete entorno laboratorio estara dentro de esta categora.

Servicio. Es un paquete que provee funcionalidades a otros paquetes y no dispone de interfaz directa con el usuario (bibliotecas del sistema, herramientas de desarrollo, middleware, etc.). Un ejemplo de servicio son las notificaciones, el sistema de plantillas o el repositorio de contenido. La estructura de un paquete consta de cuatro capas (figura 100) y sigue una estructura fija de directorios y subdirectorios, explicada en el captulo 3 (figura 32). 1. Capa presentacin o Interfaz de usuario. Es la encargada de presentar los datos al usuario. Para ello utiliza el sistema de plantillas, hojas de estilo y HTML dentro de los ficheros AOLserver Dynamic Pages o .adp (figura 101).

166

Figura 100.

Estructura de un paquete de dotLRN.

Figura 101.

Estructura de un fichero ADP de dotLRN.

167

1. Capa de programacin. Se encarga de controlar el flujo del programa. Decide que datos mostrar a la capa de usuario. El lenguaje de programacin utilizado es TCL (figura 102). 2. Capa de datos. Obtiene los datos que se mostrarn al usuario y mantiene el modelo de objetos. Para ello, utiliza el lenguaje SQL y los archivos .xql (figura 103) y .sql. 3. Capa de metainformacin. Contiene informacin sobre el paquete. Esta informacin est en formato XML y Docbook. Ejemplos, Archivo .info para la gestin gestor de paquetes de OpenACS (APM), documentacin de desarrollo y ayuda para los usuarios.

Figura 102.

Estructura de un fichero TCL de dotLRN.

168

Figura 103.

Estructura de un fichero xql de dotLRN.

Para finalizar con la arquitectura OpenACS conviene indicar que ofrece una API de base de datos, una API de TCL y una API del servidor Web AOLserver. Estas APIs sern explicadas ms en detalle cuando expliquemos el desarrollo del paquete entorno laboratorio. Desarrollo del paquete entorno laboratorio en OpenACS/dotLRN En este apartado se va a describir el proceso que se ha seguido para crear un paquete de dotLRN. Dicho paquete:

Podr ser instalado en cualquier instancia de dotLRN (portable). Y dentro de la plataforma aLF de la UNED.

Permitir utilizar los servicios de dotLRN, herramientas de comunicacin, almacn de datos, etc. (reutilizacin de servicios).

Permitir utilizar estndares educativos: paquete IMS, IMS-QTI, SCORM.

Permitir crear, gestionar y utilizar distintos tipos de laboratorio.

169

A continuacin se definen los pasos y acciones que se han llevado a cabo para crear dicho paquete: 1. Crear un paquete vacio. Para ello entramos en el APM y seleccionamos la opcin create new package. Al pulsar en dicha opcin, OpenACS mostrar un formulario (figura 102) solicitando la siguiente informacin:

Clave del paquete o Package Key. Es un identificador nico para cada paquete.

Figura 104.

Formulario para crear un paquete vacio.

Nombre del paquete o package name. Es el nombre del paquete.

Nombre del paquete en plural o Package plural.

170

Tipo del paquete o package type. Si es una aplicacin o un servicio. En nuestro caso es una aplicacin, ya que dispone de interfaz directa con el usuario.

Ncleo de OpenACS u OpenACS core. Decimos si el paquete va a ser o no del ncleo de OpenACS. En nuestro caso decimos que No.

Singlenton. Patrn de diseo que restringe la creacin de objetos de una clase.

Punto de montaje automtico o Auto-mount URI. Es el nombre nico sobre el que se montar de forma automtica nuestro paquete dentro del sitio principal.

URL del paquete o package URL. URL desde el cual se puede descargar el paquete.

Versin inicial de paquete o Initial Version. El formato de dicha versin debe ajustarse a: nmero ms significativo . Nmero menos significativo ms un sufijo opcional de: d para desarrollo, a para alpha o b para beta. Ejemplo 0.1d

Versin URL. Direccin URL para la versin inicial del paquete.

Resumen o summary. Una frase que resuma la funcionalidad del paquete.

Descripcin o description. Descripcin del paquete

Propietario principal o primary owner.

URL del autor principal o URL primary owner.

Propietario secundario o secundary owner.

171

URL del autor principal o URL secundary owner.

Organizacin o vendor. Es la organizacin encargada de distribuir el paquete.

URL de la organizacin o URL vendor. Al pulsar en el botn de create package, se crea un paquete vacio con los directorios iniciales, los archivos de metadatos y las entradas en la base de datos para nuestro paquete. 2. Se aade la instancia al servidor como aplicacin. Los pasos que se han seguido son:

Nos vamos a la administracin de dotLRNOpenACS Site-Wide AdministrationMain SiteSite Map. En el caso de disponer de la barra de desarrolladores de OpenACS, simplemente tendremos que pulsar sobre la opcin Site Map. Aparecer una relacin de los paquetes montados sobre el sitio principal.

Asociamos la URL o punto de montaje labs a nuestro paquete Entorno Laboratorio (figura 105). Es importante sealar que se pueden tener instancias de un paquete sobre cada uno de los sitios (site), cada instancia podr tener una URL, una configuracin y unos permisos diferentes. Todas ellas compartiendo el mismo cdigo y modelo de datos.

172

URL Paquete

Figura 105.

Asociamos la URL o punto de montaje labs a nuestro paquete de dotLRN.

3. Modelo de datos. En este paso se programaron los Scripts para la creacin y borrado del modelo de datos del paquete. Implementando un modelo de objetos sobre el modelo relacional de la base de datos (tablas, vistas y paquetes PL/SQL). En un principio se plante la idea de integrar un laboratorio como un portlet dentro de los cursos virtuales. Esto solamente permitira la utilizacin de dicho laboratorio dentro de la asignatura. Ms adelante se decidi que era mejor crear un grupo laboratorio donde se pudieran integrar los servicios bsicos (herramientas colaborativas, almacn de datos, autoevaluaciones, etc.) para el desarrollo de un experimento y que a su vez pudiera relacionarse con otros cursos mediante las relaciones de dotLRN. Para crear el modelo de datos se tuvo que:

173

a) Crear un tipo de grupo (dotlrn_laboratory) que herede de la clase comunidad (dotlrn_community) (figura 106).

Figura 106.

Diagrama de clases (dotlrn_community y dotlrn_laboratory).

b) Definir las propiedades del objeto mediante la creacin de la tabla dotlrn_laboratories (figura 107).

Figura 107.

Diagrama E-R de dotlrn-laboratories y dotlrn_communities.

c) Implementar los mtodos de acceso al objeto mediante paquete PL/pgSQL (dotlrn_laboratory__new y dotlrn_laboratory__delete) (figura 108) d) Crear las tablas para crear, gestionar, borrar y utilizar los laboratorios web y remotos (figura 109).

174

Figura 108.

Implementacin de los mtodos del paquete creado.

Figura 109.

Diagrama completo del modelo de datos del paquete.

175

4. Configuracin del portal del grupo laboratorio. En este paso de deben definir las pginas y herramientas que van a formar parte de dicho portal. Esto se realiza incluyendo los parmetros laboratory_pages_csv (pginas del portal) y laboratory_applets (herramientas) en el archivo de definicin del paquete labs.info, tabla 7.1

Tabla 7.1. Parmetros de configuracin del portal.

Parmetro
grupo_page_csv

Valor
#pagename#,#layout#,#accesskey#

El acceskey es utilizado para temas de accesibilidad. Como un atajo de teclado

laboratory_page_csv

#labs.Home#,#theme-zen.Zen_2_column#; #labs.Experiments#,#themezen.Zen_1_column#; #labs.Calendar#,#theme-zen.Zen_1_column#; #labs.Laboratory#,#theme-zen.Zen_1_column#; #labs.Synchronous_Communication#,#theme-zen.Zen_2_column#; #labs.Asynchronous_Communication#,#theme-zen.Zen_2_column#; Wikilab,#theme-zen.Zen_1_column#; #labs.Self_Assessment#,#themezen.Zen_2_column#; #labs.Evaluation#,#theme-zen.Zen_2_column

grupo_applets

Listado de los applets

laboratory_applets

dotlrn_dotlrn,dotlrn_news,dotlrn_faq,dotlrn_user_tracking, dotlrn_static,dotlrn_syllabus,dotlrn_calendar,dotlrn_fs,dotlrn_forums, dotlrn_chat,dotlrn_portlet,dotlrn_bm,dotlrn,dotlrn_homework_applet, dotlrn_weblogger,dotlrn_xowiki,dotlrn_evaluation,dotlrn_assessment

5. Creacin del portal. Instancia y monta la plantilla del portal para el tipo de grupo laboratorio. Procedimientos que se lanzan en la instalacin, instanciacin actualizacin y montaje del paquete. Pueden ejecutarse antes o despus de estas opciones. En nuestro caso hemos utilizado una callback que se ejecuta despus de la instalacin del paquete. En el diagrama de componentes (figura

176

110) veremos que utiliza una API creada por nosotros para establecer un punto de montaje del nuevo grupo creado.

instantiate_and_mount Callback new_edu_type portal API labs-procs

Figura 110.

Llamadas de la callback creada a la API del paquete laboratorio.

6. API. Est compuesta por tres procedimientos llamados:

labs::instantiate_and_mount Instancia y monta el nuevo tipo de grupo laboratorios. En la figura 111 podemos ver el diagrama de secuencia que sigue dicho procedimiento.

dotlrn_community labs-procs site_node parameter

get_type_node_id Parent_node_id get

labs: Instantiate and mount

Parent_node One_community_type_package_key Package_key Instantiate_and_mount Package_id Set_value (dotlrn_level_p, community_type_level_p, community_level_p) set_type_package_id

Figura 111.

Diagrama de secuencia de labs::instantiate_and_mount.

labs::new_edu_type_portal crea la plantilla del portal para el grupo laboratorios. En la figura 112 podemos ver el diagrama de secuencia que sigue dicho procedimiento.

177

labs::access, dependiendo del tipo de laboratorio construye la URL de acceso a los laboratorios.

labs-procs

dotlrn_community

dotlr_applet

portal

parameter

service_contract

get_from_package_id Lista de pginas get_from_package_id

labs: new_edu_type _portal

Lista de applets create applet_exists_p boolean applet_call AddPortlet

Figura 112.

Diagrama de secuencia de labs:new_edu_type_portal.

Adems de la creacin de esta API, ha sido necesario modificar dos procedimientos del ncleo de dotLRN. Estos procedimientos son:

dotlrn/tcl/community-procs.tcl

Se

modifico

la

funcin

get_default_roles_not_cached para utilizar los roles por defecto de administrador y miembro en el nuevo tipo de grupo laboratorio.

Portlets de grupos del usuario o dotlrn/www/dotlrn-main-portlet-postgresql.xql. fue modificado para obtener el nuevo tipo de grupo. o dotlrn/www/dotlrn-main-portlet.adp. se modific para pintar el nuevo tipo de grupo en una seccin nueva. o dotlrn/www/dotlrn-main-portlet.tcl. se modific para que el nuevo tipo aparezca en la pestaa de cursos.

178

El resultado de modificar estos archivos es la figura 113.

Figura 113.

Portlet para visualizar el grupo Laboratories creado en dotLRN.

dotlrn-calendar/tcl/dotlrn-calendar-procs.tcl. Se modific para que a la hora de crear un nuevo grupo, el portlet de calendario se colocase en la pgina definida para ello (pgina Calendar).

dotlrn-dotlrn/tcl/dotlrn-dotlrn-procs.tcl. Se modific para que a la hora de crear un nuevo grupo, el portlet de miembros se colocase en la pgina definida para ello (pgina People).

dotlrn-fs/tcl/dotlrn-fs-procs.tcl. Se modific para que a la hora de crear un nuevo grupo, el portlet de documentos se colocase en la pgina definida para ello (pgina Experiments). 7. Interfaz de administrador (figura 114). Se ha creado una interfaz que permite que un administrador de dotLRN pueda gestionar los laboratorios dentro del LMS y estos puedan ser utilizados por los dems roles del LMS (estudiantes, profesores, tutores, etc.). A continuacin describiremos brevemente cada una de ellas:

179

B) Gestionar tipos
laboratorios

Tipo Laboratorios

C) Gestionar tipos
acceso laboratorios I.U. Administrador

Tipos de acceso a laboratorios

D) Gestionar
laboratorios

Laboratorios

A) Gestionar grupos

Grupos

Figura 114.

Implementacin del caso de uso de gestin de laboratorios, administrador.

A) Crear un grupo laboratorio. Esta opcin utiliza todos los ficheros y elementos que hemos vistos en los pasos anteriores. Los pasos que lleva a cabo son: 1. Instanciar el paquete del objeto dotlrn_laboratory. 2. Obtener el portal_id del tipo de grupo. 3. Crear el portal. 4. Crear los segmentos de relaciones. 5. Obtener el Nodo de tipo de la comunidad o del padre del grupo. 6. Instanciar y montar el paquete dotlrn_laboratory. 7. Establecer el package_id. 8. Aadir los applets. B) Gestionar tipos laboratorios permite aadir, modificar o borrar tipos de laboratorios. Por ejemplo, laboratorio remoto, laboratorio web, etc.

180

C) Gestionar tipos acceso laboratorios permite aadir, modificar o borrar tipos de conexin. Por ejemplo, laboratorios que necesitan autenticacin mediante usuario y contrasea por URL, si es de acceso libre, etc. D) Gestionar laboratorios permite aadir, modificar o borrar laboratorios. Estos laboratorios son los que podrn ser utilizados por los profesores y estudiantes. A parte de incluir informacin como la URL de acceso, tambin es necesario indicar el tipo de laboratorio y como se debe acceder a l. 8. Portlet de administracin del grupo. Est interfaz permite realizar las acciones necesarias para que un administrador pueda gestionar los diferentes servicios y herramientas del grupo (calendario, subgrupos de usuarios, correo, chat, etc.) y asociar laboratorios dentro de un grupo (figura 115).

Aadir

Gestionar herramientas Administrador del grupo I.U

Deshabilitar

Herramientas

Situar en el portal

Gestionar laboratorios

Asociar

Laboratorios

Quitar

Figura 115.

Implementacin del caso de uso de para los laboratorios, administrador grupo.

9. Portlet de usuario. Esta interfaz es la encargada de mostrar los laboratorios asociados a ese grupo y dar acceso al usuario (figura 116)

Mostrar laboratorios grupos Miembro del grupo I.U Laboratorios Acceso a laboratorios

Figura 116.

Implementacin del caso de uso de para los laboratorios, miembro del grupo.

181

Este portlet de usuario incluye un fichero muy importante que le hemos dado el nombre de view.tcl, aunque dedicaremos un apartado a hablar de l, podemos decir que contiene la lgica para dar acceso al laboratorio seleccionado por el usuario del curso. 10. Por ltimo, se cre un applet que es el encargado de definir las propiedades (la pgina del portal en la que se visualizar el portlet, el estado (oculto, minimizado, etc.), la ordenacin dentro de la pgina) y los service contract (aadir un portlet a un grupo, aadir el portlet y el applet a la comunidad, etc.) del portlet de laboratorios dentro del portal del grupo laboratorio. Una vez creado el paquete, este podr ser utilizado en cualquier organizacin que disponga de un servidor con dotLRN.

7.2.2

Desarrollo de un mdulo de actividad en Moodle

Como se ha comentado en captulos anteriores, Moodle permite que un programador pueda crear mdulos de actividad y bloques que aadan nuevas funcionalidades al sistema. A diferencia de lo realizado en dotLRN, se ha desarrollado un mdulo que permite la gestin de laboratorios dentro de un curso y no un grupo. A continuacin se describe el mdulo que se ha creado, y posteriormente la modificacin sobre el bloque de administracin de Moodle. Creacin de un mdulo de actividad para incluir laboratorios en un curso Un mdulo de actividad en Moodle dispone de una estructura estndar que puede verse en la figura 40. Moodle dentro de sus pginas dedicadas a los desarrolladores ofrece un conjunto de plantillas para la creacin de mdulos. Nosotros nos hemos basado en una de ellas

182

A continuacin se describe, paso a paso, el desarrollo realizado para crear el mdulo laboratorios de Moodle: 1. Crear un directorio dentro de la carpeta moodle/mod con el nombre del mdulo a desarrollar, en nuestro caso, lo hemos llamado wlab. Dentro de esta carpeta se irn creando toda la estructura de directorios y ficheros necesarios para: Creacin de la base de datos utilizada por el mdulo, lgica de negocio e interfaces de usuario. 2. Definir las tablas del mdulo wlabs. Para ello Moodle ofrece una capa de abstraccin de base de datos para evitar tener trabajar, de forma directa, con cdigo para Oracle o MySQL. Los pasos a realizar son: a) Es por tanto muy importante haber definido las tablas e informacin que va a manejar nuestra actividad. Normalmente la tabla principal del modelo debe tener el mismo nombre que el mdulo y es la encargada de almacenar las instancias de la actividad en un curso. En nuestra primera versin del mdulo wlab. Se ha definido el siguiente modelo entidadrelacin (figura 117): Tabla wlab. Contiene la informacin de instancias laboratoriocurso. Los campos son: nombre que tiene el enlace del laboratorio en el curso, identificador del curso e identificador del laboratorio. Adems de esto, existe una tabla en cursos que mantiene informacin de todas las instancias realizadas sobre un curso Tabla wlab_list. Contiene todos los laboratorios disponibles en Moodle.

183

wlab PK id

wlab_type wlab_list PK id name url subject description id_access id_type

n
name id_curso id_lab

PK

id name description

n n
wlab_access PK id name description

1
wlab_experiment PK id id_lab id_user start_date end_date file_experiment session_id

n n
PK id id_lab username Login id_session

1
wlab_login

Figura 117.

Modelo entidad relacin del mdulo de actividad curso.

Tabla wlab_type. Contiene informacin sobre el tipo del laboratorio: web, remoto, etc.

Tabla wlab_access. Contiene informacin sobre el tipo de acceso al laboratorio. Por ejemplo a travs de nombre de usuario y clave.

Tabla lab_login. Contiene la informacin necesaria (nombre de usuario, contrasea o identificador de sesin) para conectarse al laboratorio.

Tabla wlab_experiment. Contiene los experimentos realizados dentro del LMS.

b) Crear la carpeta wlabs/db donde se guarda el fichero install.xml. Este fichero debe existir siempre, independientemente de si nuestro mdulo va a necesitar o no crear nuevas tablas. c) Install.xml contiene una definicin de las tablas del mdulo en un formato XMLDB modificado por Moodle (figura 118)

184

Cabecera

Tablas

Declaraciones

Figura 118.

Estructura del fichero install.xml.

En nuestro caso se cre un install.xml con las tablas wlab_list y wlab. wlab_list contiene actualmente la password y nombre de usuario de acceso. 3. Una vez que se ha creado la base de datos, se debe pasar a la lgica del mdulo. a) Crear el fichero mod.html. Este fichero, es un formulario utilizado desde course/mod.php y aparece cuando el administrador del curso pretende aadir o editar una instancia de un laboratorio en un curso. El formulario, por tanto, mostrar los campos a rellenar para crear o editar una instancia del mdulo dentro de un curso. En nuestro caso mod.html solicita los datos de:

Name. Nombre de la instancia.

Lab Name. Nombre del laboratorio asociado a esa instancia.

Visible. Si esta visible o no.

Groups mode. Si deseo hacerlo visible para todos los usuarios del curso o solo para algunos.

185

Adems de la informacin que rellena el administrador del curso, tambin se pasa otros datos ocultos como: curso, mdulo del curso, etc. b) Crear el fichero lib.php. Es la librera del mdulo, es decir, en el se encuentran todas las funciones que va a necesitar el mdulo u otros mdulos que quieran realizar operaciones sobre l. Conviene destacar las siguientes funciones:

wlab_add_instance($wlab). Crea una instancia con los datos rellenados en el mod.html. Aade un registro a la tabla wlab.

wlab_update_instance($wlab).

Actualiza

la

instancia

seleccionada y mostrada en mod.html. Actualiza el registro de la tabla wlab.

wlab_delete_instance($id). Borra la instancia y los datos asociados a dicha instancia. Devuelve true o false. c) Crear el fichero view.php. Este fichero muestra todas las instancias de los laboratorios en un curso. Para mostrarlas se le pasa el identificador del curso. d) Crear el fichero versin.php. Donde se indica informacin del paquete 4. Al igual que en dotLRN (view.tcl), existe un fichero view.php encargado de gestionar el acceso a los laboratorios. Modificacin del Bloque de Administracin de Moodle El mdulo de actividad creado para laboratorios permite crear, modificar y borrar instancias de ellos dentro de los cursos de dotLRN. Pero para realizar estas operaciones es necesario que antes el administrador de Moodle incluya toda la

186

informacin de los laboratorios disponibles en el LMS. Por esta razn, se ha modificado el bloque de Administracin de Moodle (119).

Figura 119.

Bloque de Administracin de Moodle.

Como su propio nombre indica, el bloque de administracin Moodle permite administrar los servicios y herramientas de Moodle. Algunas de estas son:

Cursos: Aadir y editar cursos, establecer la configuracin por defecto de los cursos, etc.

Idioma o Language. Permite establecer el lenguaje de la plataforma, etc.

Red o networking. Donde se puede establecer control de acceso mediante single sign-on.

Informes o reports. A parte de estas opciones, es necesario incluir otra categora, que nosotros hemos llamado laboratories. Esta categora permitie que el administrador de Moodle tenga las opciones de aadir, editar o borrar laboratorios. Para ello, se han realizado las siguientes modificaciones sobre el bloque de aministracin: 1. Abrir el fichero top.php que se encuentra en la carpeta moodle/admin/settings. Una vez abierto aadir la lnea:
$ADMIN->add('root', new admin_category('laboratories', get_string('laboratories','admin')));

187

Como se puede ver, esta lnea crea una categora dentro del bloque de administracin de Moodle 2. Se crea el fichero laboratories.php dentro de la carpeta moodle/admin/settings. Este fichero aade las opciones que se mostrarn en la categora creada anteriormente.
$ADMIN->add('laboratories', new admin_externalpage('labs', get_string('add laboratories',

'laboratories'), "$CFG->wwwroot/$CFG->admin/laboratories/add.php", 'moodle/site:config'));

Como se puede ver, esta lnea crea la opcin add laboratories dentro de la categora. Y la asocia a una pgina php encargada de realizar dicha operacin. En nuestro caso tendremos cinco opciones: Aadir tipos de laboratorio, aadir tipo de acceso, aadir laboratorio, editar laboratorio, borrar laboratorio. El resultado de estos dos puntos es el mostrado en la figura 120.

Figura 120.

Bloque de Administracin de Moodle modificado.

3. Se crea una carpeta nueva llamada laboratories dentro de la carpeta moodle/admin/settings. Dentro de esta carpeta se introducen los ficheros:

188

a. add.php. Aade un laboratorio y los datos del laboratorio para que puedan ser instanciados en los cursos de Moodle. b. modify.php. Aade un laboratorio y los datos del laboratorio para que puedan ser instanciados en los cursos de Moodle. En desarrollo. c. delete.php. borra un laboratorio y los datos del laboratorio dentro de Moodle. En desarrollo. d. Addtype.php. Aade un tipo de laboratorio. En desarrollo. e. Addaccess php. Aade un tipo de acceso. En desarrollo.

7.2.3

Desarrollo del archivo view.tcl de dotLRN y view.php de Moodle

Este fichero es el encargado de conectar con los diferentes laboratorios. Dependiendo del laboratorio, ser necesario enviarle:

El usuario y contrasea mediante URL.

El usuario y contrasea. Una vez aceptado se le enva un identificador de sesin para conectarse.

Usando un servicio de autenticacin.

Usando certificados.

Otros mtodos Uno de los objetivos, en un futuro, es intentar utilizar un single sign-on que reduzca la lgica de conexin entre laboratorios y LMS. Mientras tanto, es necesario que el archivo view se encargue de obtener:

Obtener el tipo de acceso del laboratorio.

189

Recoger los datos de conexin que estn en la base de datos.

Enviar la informacin al servidor del laboratorio. Esto es lo que realiza el los ficheros view.tcl creado en el paquete laboratorio de dotLRN y el view.php del mdulo laboratorio de Moodle.

7.3

Integracin de laboratorio en LMS de iniciativa privada (WebCT)

El principal problema de los sistemas de gestin de aprendizaje de iniciativa privada es conocer su arquitectura. Si no se conoce la arquitectura, difcilmente se podrn crear nuevas herramientas o reutilizar las ya existente. Y en el caso de conocerla, puede ocurrir que no se tenga derecho a modificarla. Por ello, en este caso, para integrar los laboratorios dentro de WebCT, el administrador del curso deber incluir un link por cada uno de los laboratorios que desee incluir en el curso. Este link enlaza a la pgina de acceso del laboratorio. En ocasiones se podrn crear pginas con lgica de acceso dentro de WebCT, siempre y cuando la institucin y el administrador del LMS lo permitan. En este caso, se ha creado una categora con el nombre de laboratorios dentro de WebCT, y se ha creado una pgina por cada uno de los laboratorios: laboratorio remoto de rosario, laboratorio Web de la universidad Hopkings y el laboratorio Web del IEEC. Algunos problemas que surgen son:

Los profesores deben crear la categora laboratorio y sus pginas web de acceso al laboratorio para cada curso.

En el caso de que se necesite autenticacin (los datos de esta, deben estar en las pginas de programacin).

190

En muchas ocasiones las instituciones no dejan que cualquier persona que no sea un programador pueda incluir pginas con programacin. Problemas de seguridad.

No se crea una base de datos para almacenar laboratorios y experimentos. En el momento que cambi algn dato como la URL. Todas las pginas que contengan ese laboratorio deben modificarse una a una.

7.4

Resumen

La arquitectura propuesta permite incluir un mdulo o paquete para: 1. Que los profesores de una institucin puedan incluir laboratorios, sin tener que conocer nada de programacin y de una manera sencilla. 2. Que los estudiantes puedan acceder a estos laboratorios de forma transparente y desde un nico entorno de trabajo. Para ello se han creado un paquete en dotLRN y un mdulo en Moodle. Estos, an siendo una primera versin ya facilita estas funcionalidades. Tambin permiten que otras universidades que utilicen dotLRN o Moodle puedan instalar el paquete y trabajar con l (reutilizacin) de manera fcil y sencilla. Por ltimo, se ha indicado como se trabajara con una plataforma de iniciativa privada, WebCT, para incluir laboratorios en ella.

191

192

CAPTULO 8.

EJEMPLOS PRCTICOS REALIZADOS

8.1

Introduccin

En este captulo se van a mostrar algunos ejemplos de cmo utilizar los paquetes creados para Moodle y dotLRN. Es importante remarcar, que estos paquetes no vienen en la instalacin por defecto de dotLRN y Moodle, y que si se quieren utilizar deben instalarse.

8.2

Ejemplo de utilizacin del paquete de dotLRN

A continuacin se va a definir el mtodo de trabajo y los perfiles que intervienen. 1. El Administrador de dotLRN. Podr: crear un grupo laboratorio, gestionar los tipos de laboratorio, gestionar los tipos de acceso de los laboratorios, gestionar un laboratorio. Todas estas operaciones le aparecern al seleccionar el enlace de administracin de dotLRN (figura 121).

Figura 121.

Opciones del administrador.

o Aadir grupo lo que hace es crear el portal del grupo. Al pulsar sobre el enlace, aparecer un formulario pidindole: nombre del grupo, tipo del grupo, en este caso dotlrn_laboratory y la descripcin (figura 122).

193

Figura 122.

Formulario de creacin de un grupo laboratorio.

Esto crear un enlace en el portlet de grupo (figura 113) con el nombre laboratorio de electrnica y el portal (figura 123) con todas las herramientas y portlets incluidos en el grupo: comunicaciones sncronas, asncronas, el almacn de datos (experiments), calendario, autoevaluacin, el portlet de entorno laboratorio, etc.

Figura 123.

Portal del laboratorio de electrnica, que pertenece al grupo laboratorios.

o Gestionar los tipos de laboratorio. Aadir, modificar y borrar tipos de laboratorios dentro de dotLRN. o Gestionar los tipos de acceso de los laboratorios. Aadir, modificar y borrar los tipos de acceso de laboratorios dentro de dotLRN.

194

o Gestionar laboratorios. Aadir, modificar y borrar los laboratorios dentro de dotLRN. Esta ltima, hace uso de los datos insertados en las anteriores. Las tres ltimas opciones son muy similares, as que se ver la de aadir, editar o modificar un laboratorio. Una vez que se ha pinchado en el enlace de laboratories, aparecer un formulario con el listado de los laboratorios ya insertados y las opciones de aadir nuevos, editar y borrar (figura 124).

Figura 124.

Pantalla para gestionar laboratories.

Si se selecciona aadir nos saldr un formulario con los datos para el laboratorio: nombre, URL, tipo de laboratorio, tipo de acceso, etc. Una vez relleno, se acepta y aparecer en la lista de laboratorios. Para editar o borrar se deber seleccionar uno de los laboratorios. Editar dejar modificar los datos del laboratorio y borrar pedir una confirmacin de borrado. 2. Una vez que el administrador de dotLRN ha incluido laboratorios, el administrador del curso podr pulsar sobre la opcin de dotLRN de administracin del curso y aadir o borrar laboratorios. Esta operaciones se

195

realizan dentro del portlet de administracin del curso llamado entorno de laboratorio (figura 125)

Figura 125.

Portlet para aadir y borrar laboratorios de un curso.

En la figura 125 podemos ver que se han aadido tres laboratorios: o Weblab Deusto. Es un laboratorio remoto cuyo acceso se hace por usuario, contrasea e identificador de sesin. Estos datos se encuentran en la base de datos. La forma de conexin es transparente para el administrador del curso y para el estudiante. o Lerro. Es un laboratorio remoto de la universidad de Rosario, Argentina, cuyo acceso se hace por usuario, contrasea. Estos datos se encuentran en la base de datos. La forma de conexin es transparente para el administrador del curso y para el estudiante. o Dieec. Laboratorio web del departamento de ingeniera elctrica, electrnica y de control de la UNED. En este caso no necesita autenticacin. 3. Una vez que han sido aadidos estos laboratorios al curso, cualquier profesor o estudiante que acceda al curso podr ver dentro de su portal el portlet entorno laboratorio que le mostrar los laboratorios a los que tiene acceso (figura 126).

196

Figura 126.

Portlet del portal de estudiante y profesor con el listado de los laboratorios.

El estudiante podr por tanto acceder a las herramientas del LMS o acceder a los laboratorios de forma directa y sin cambiar de herramienta. Si el estudiante, por ejemplo pulsara en el laboratorio de la universidad de Deusto, accedera a dicho laboratorio sin tener que autenticarse. El resultado sera el mostrado en la figura 127.

Figura 127.

Acceso a los experimentos del laboratorio remoto de la universidad de Deusto.

197

8.3

Ejemplo de utilizacin del mdulo de Moodle

A continuacin se va a definir el mtodo de trabajo y los perfiles que intervienen. 1. Una vez instalado el mdulo wlab de Moodle. El administrador de Moodle deber incluir todos los datos de los laboratorios que desea tener en Moodle. Para realizar esta tarea accede a las opciones presentadas en el bloque de administrador de Moodle (figura 120). Cada una de las opciones: aadir tipo de laboratorio, aadir acceso a laboratorios, aadir laboratorio, modificar laboratorio y borrar laboratorio. Deber mostrar un conjunto de formularios que permiten realizar dichas operaciones. Por ejemplo, aadir laboratorio muestra el formulario, ya implementado, (figura 128).

Figura 128.

Formulario para aadir un laboratorio en Moodle.

2. Una vez introducidos los datos de todos los laboratorios disponibles para ese servidor de Moodle. El administrador del curso podr elegir las actividades que quiera incluir en el curso. Una de ellas ser wlab (figura 129). Una vez seleccionada, aparecer un formulario que crear una instancia de un

198

laboratorio dentro del curso. Dicho formulario pide el nombre de la instancia, el laboratorio a instancia, si este enlace creado es visible o no, etc (130).

Figura 129.

Seleccionamos la actividad wlab.

Figura 130.

Instancia del laboratorio remoto de la universidad de Deusto.

3. De esta manera se pueden incluir tantos laboratorios como se quiera. Una vez que el estudiante entra en el curso podr trabajar con las herramientas que le ofrece el LMS (foros, chats, documentos, etc.) y por supuesto acceder a los laboratorios. En la figura 131 se puede ver que el curso ha incluido tres laboratorios: o Laboratorio remoto de Deusto. o Laboratorio web de la universidad Hopkins. o Laboratorio web que permite explicar las leyes de ohm.

199

Al lado de estos laboratorios se puede ver unos smbolos. El aspa permite eliminar la instancia del laboratorio y la mano permite actualizar el nombre de la instancia o asociarle otro laboratorio

Figura 131.

Instancias de laboratorios en un curso Moodle.

4. Por ltimo el estudiante pulsara sobre el enlace del laboratorio que quiere utilizar. En la figura 132 se puede ver el resultado de acceder al laboratorio de Deusto desde Moodle.

Figura 132.

Acceso a los experimentos del laboratorio remoto de la Universidad de Deusto.

8.4

Ejemplo de utilizacin de WebCT y laboratorios

Al ser de iniciativa privada no se puede conocer su arquitectura y aadir elementos para crear un nuevo mdulo. Al tener el perfil de profesor, se restringe la opcin de poder crear ficheros php para controlar el acceso.

200

Por tanto, si se quieren introducir laboratorios en WebCT con el perfil de profesor, se debe: 1. Crear un fichero html que contenga el laboratorio a incluir. 2. Crear el rea laboratorio (figura 133).

Figura 133.

Creacin de la categora laboratorios en un curso de WebCT.

3. Subir el fichero dentro del rea laboratorio, nosotros lo hemos hecho en contenidos. Se han aadido cuatro laboratorios: Hopkinhs, Dieec y Rosario. El resultado se puede ver en la figura 134.

Figura 134.

Listado de laboratorios disponibles en un curso de WebCT.

201

4. El estudiante ver la pgina mostrada en la figura 134. Al pulsar sobre alguno de los enlaces se le cargar la pgina con el laboratorio. Por ejemplo, si se pulsa sobre el laboratorio de Karnaugh del DIEEC de la UNED, se muestra dicho laboratorio (figura 135). De nuevo, es importante remarcar, que no existe lgica para autenticarse con los laboratorios. Pero si se puede incluir conocimiento terico y prctico en una sola herramienta.

Figura 135.

Laboratorio Karnaugh del DIEEC (UNED) desde WebCT.

8.5

Ejemplo de utilizacin del paquete SCORM

Como ya se ha visto, SCORM es un estndar de contenidos, que permite incluir un conjunto de informacin (html, Jpeg, etc.) y que est pueda ser utilizada por cualquier LMS que lo soporte. Esta es una buena alternativa a utilizar, siempre y cuando no se introduzca lgica de negocio o intercambio de informacin entre sistemas. Nosotros hemos creado un objeto SCORM con el laboratorio remoto del DIEEC UNED y se integr en Claroline y Moodle, sin problemas (figura 136).

202

Figura 136.

SCORM instalado en Moodle.

Los principales problemas son:

El intercambio de informacin, ya que es un objeto de contenidos.

No todos los LMS soportan la misma versin de SCORM. Actualmente existe un proyecto para utilizar el entorno de ejecucin de SCORM con Webservices [LETSI, 2009]

8.6

Resumen

En este captulo hemos visto como utilizar el paquete de dotLRN y el mdulo de Moodle. Las funcionalidades ofrecidas a cada uno de los perfiles y la utilizacin de los servicios de los LMS con los laboratorios. Tambin, hemos visto como utilizar laboratorios en la plataforma de iniciativa privada WebCT. Por ltimo hemos visto la posibilidad de crear paquetes SCORM con laboratorios y la problemtica de cmo incluir elementos de comunicacin con otros sistemas dentro del SCORM.

203

204

CAPTULO 9. FUTURAS

CONCLUSIONES Y LNEAS DE INVESTIGACIN

9.1

Conclusiones y aportaciones

Como se ha podido ver en los en los primeros captulos los LMS y laboratorios son dos soluciones educativas, que hasta ahora han estado claramente diferenciadas. Por este motivo se ha planteado una arquitectura y desarrollado parte de ella para poder (figura 137):

Utilizar el servicio de autenticacin del LMS, dando transparencia de acceso a los laboratorios web y remotos.

Utilizar los servicios de los sistemas de gestin de aprendizaje, como: gestin de contenido, herramientas colaborativas, etc., para los diferentes laboratorios, independientemente de su arquitectura.

Utilizar estndares educativos: paquetes IMS, IMS-QTI, SCORM, etc.

Comunicar los laboratorios y LMS de una forma estndar, utilizando una API comn. Por supuesto, comunicar laboratorios aislados en Internet y comunicar los laboratorios proporcionados con el proyecto iLab del MIT.

Sacar de la implementacin de los laboratorios el servicio de reservas. Y que este servicio sea general para todos los LMS, laboratorios y usuarios. Para poder llevar a cabo todo lo anterior se ha definido una arquitectura capaz de: comunicar e integrar laboratorios dentro de un LMS, reutilizar los servicios de los LMS, utilizar los estndares e-learning soportados por los LMS, etc. As:

205

Situacin actual

Autenticacin

Herramientas de Grupo

Interfaz de Usuario

Autenticacin Herramientas de Evaluacin Contenidos (No SCORM) Laboratorio

Grupos y Gestin de Perfiles

Herramientas de Evaluacin (IMS-QTI) LMS

Herramientas de Comunicacin

Contenidos (SCORM, IMS)

Herramientas de Comunicacin

Servicio de reservas

Grupos y Gestin de Perfiles

Base de Datos

Seguridad

Gestin de Logs de Experimentos

Logs

Situacin despus de aplicar la arquitectura planteada

Interfaz de Usuario Autenticacin bsica

Autenticacin

Herramientas de Grupo
Herramientas de Evaluacin (IMS-QTI) LMS Servicio de reservas

Grupos y Gestin de Perfiles

Laboratorio

Contenidos (SCORM, IMS)

Herramientas de Comunicacin

Base de Datos

Seguridad

Gestin de Logs de Experimentos

Logs

Figura 137.

Reutilizacin de los servicios y estndares ofrecidos por los LMS en los laboratorios Web y remotos.

206

Se ha descrito la arquitectura y la metodologa a seguir para crear nuevos servicios en sistemas de gestin de aprendizaje de cdigo abierto, como: dotLRN, Moodle, Sakai y Claroline. Posteriormente se han desarrollado e implementado en dotLRN y Moodle un servicio capaz de gestionar e incluir laboratorios dentro de sus cursos. As: o El administrador del LMS, ser el encargado de aadir, borrar o modificar la informacin (descriptiva, de acceso, etc.) de los laboratorios que estarn disponibles en el LMS. o El administrador del curso podr aadir y borrar laboratorios dentro del curso que administra. No se debe preocupar de programar el acceso a los laboratorios o la recepcin de informacin. Al mismo tiempo podr seguir creando herramientas de chats, foros, almacenes de datos dentro de su curso, y utilizar los estndares elearning para reutilizar contenidos y evaluaciones que ya tena creados. o El profesor y estudiante podr utilizar los laboratorios aadidos al curso en el que este matriculado y utilizar el resto de servicios ofrecidos por el LMS (chats, foros, etc.).

Se ha definido una arquitectura de comunicacin entre los LMS y los laboratorios que sea independiente de las arquitecturas implementadas en cada uno de los sistemas a comunicar. Por ello se ha definido una arquitectura basada en bus de servicios de empresa o ESB y se han indicado las posibilidades que dicha arquitectura ofrece.

Se ha descargado a los programadores de laboratorios de la creacin de servicios como: chats, foros, contenidos, etc.. Ya que dichos servicios ya estn disponibles en los LMS.

207

Se ha indicado la posibilidad de reutilizar y mostrar contenido y evaluaciones utilizando los estndares e-learning soportados por los distintos LMS.

Tambin se ha descrito e implementado un ejemplo de utilizacin de laboratorios dentro de una plataforma de aprendizaje de iniciativa privada llamada WebCT.

9.2

Lneas de investigacin futuras

A continuacin, se van a comentar algunos de los caminos en los que se contina trabajando para llegar a una integracin total.

9.2.1

Creacin de mdulos de otros LMS de cdigo abierto

Actualmente se han programado dos mdulos para dotLRN y Moodle. En el futuro se debern desarrollar el mdulo de gestin de laboratorios en Skai, Claroline, aLF, etc. Por supuesto tambin aadir se pueden aadir nuevas funcionalidades al mdulo:

Posibilidad de tener un conjunto de laboratorios preinstalados en las bases de datos.

Almacenar los experimentos y resultados en el LMS.

Utilizar las herramientas de seguimiento en los Laboratorios.

9.2.2

aLF y Utilizacin de Laboratorios

aLF es la plataforma utilizada en la UNED, basada en dotLRN. Actualmente se est trabajando en la creacin del paquete gestin de laboratorios para aLF, con el objetivo de que los profesores de la UNED puedan empezar a incluir de manera sencilla y cmoda laboratorios a sus cursos virtuales.

208

9.2.3

Desarrollo de la arquitectura de comunicacin LMS y laboratorios

Se ha visto que los laboratorios siguen arquitecturas heterogneas. El MIT intento conectar estas arquitecturas con su proyecto iLab. Actualmente se est trabajando con el MIT para establecer una API de servicios que permita conectar los LMS con el servicio Broker. Para ellos se trabaja en:

Informacin a intercambiar

Servicios necesarios en el lado del LMS y en el del servicio broker. Al mismo tiempo se est colaborando con la universidad de Deusto y la universidad de Rosario (Argentina) para conectar no solo iLab sino cualquier otro laboratorio.

9.2.4

Global Online Laboratory Consortium

Recientemente se ha creado un consorcio con el nombre de Global Online Laboratory Consortium [GOLG, 2010]. Este consorcio est formado por un gran nmero de instituciones, entre ellas:

Massachusetts Institute of Technology, (Estados Unidos).

University of Queensland, (Australia).

University of Technology, Sydney, (Australia).

Carinthia University of Applied Sciences, (Austria).

Universidad de Deusto, (Espaa).

Departamento de Ingeniera Electrica, Electrnica y de Control (UNED), (Espaa).

209

Hasta ahora se han realizado dos reuniones (Boston y Sydney), para formar dicho consorcio y establecer los caminos a seguir para disear una arquitectura comn en laboratorios. Algunos de los proyectos en los que se trabaja son:

Utilizacin de Single sig-on en laboratorios.

Utilizacin de estndares para crear un repositorio de laboratorios.

Estudio de estndares e-learning para reutilizacin en entornos de aprendizaje.

Integracin con LMS y laboratorios. Estos campos afectan al LMS. As estamos trabajando en:

Crear una herramienta, para los profesores que utilizan los LMS, capaz de buscar en repositorios de laboratorios.

La mayora de los LMS soportan mecanismos de acceso nico, por lo que podran conectarse con el acceso nico que implementen los laboratorios.

Comunicar el LMS con otros servicios, como el servicio de reserva. As podemos hacer que el LMS se conecte a dicho servicio, el estudiante pueda reservar un experimento de un laboratorio, que el estudiante pueda utilizar los servicios de aviso del LMS para que le informe de la fecha y hora del experimento, etc.

9.2.5

Sloodle y el mdulo de gestin de laboratorios

Sloodle es un proyecto Open Source que utiliza moodle y second life. Uno de los trabajos es intentar que los estudiantes del curso de Moodle puedan estar en Sloodle y trabajar con los laboratorios que ofrece el mdulo o paquete laboratorios.

210

9.2.6

Creacin e implantacin de nuevos laboratorios en el DIEEC

Se acaba de pedir una subvencin para adquirir Visir y ya se dispone de algunos dispositivos que permiten conectarse a Internet y por tanto es posible crear un laboratorio remoto para conectarlo a los LMS y conseguir una solucin integrada.

211

212

CAPTULO 10. CURRICULUM VITAE DE ELIO SAN CRISTBAL RUIZ

Formacin Acadmica Informe favorable de la ANECA para profesor colaborador. 2007. Diploma de Estudios Avanzados (D.E.A) Dentro del programa de Doctorado:

Sistemas de Ingeniera Elctrica, Electrnica y de Control, UNED. 2005. Ttulo de Ingeniero Informtico, especialidad en Ingeniera del Software, por la Universidad Pontificia de Salamanca. 2002 Ttulo de Ingeniero tcnico en Informtica de Sistemas por la Universidad Pontificia de Salamanca. 1998. Experiencia Laboral y Docente Tcnico en desarrollo de aplicaciones de soporte a la educacin y gestin en el Centro de Servicios Informticos de la UNED. Desde el 2003 hasta la actualidad Profesor asociado en el departamento de ingeniera elctrica, electrnica y de control de ingenieros industriales. Desde el 2008-Actualidad. Profesor investigador en el departamento de ingeniera elctrica, electrnica y de control de ingenieros industriales Mayo-2007- 2008. Profesor asociado en el departamento de ingeniera elctrica, electrnica y de control de ingenieros industriales 15-Febrero-2006-15 Febrero-2007. Tutor de Programacin I de la UNED, Centro Asociado de Tres cantos 2003Actualidad Actualidad. Y tutor de Autmatas II de la UNED, Centro Asociado de Tres cantos 2005- Actualidad

213

Tutor de Ingeniera del software de gestin y de redes de computadores, Centro Asociado las rozas 2007-2009 Programador de sistemas Web en el Instituto Universitario de Educacin a Distancia (UNED). Desde 1998 hasta el 2002 Artculos recientemente publicados en congresos Sancristobal, E., Martn, S., Gil, R., Lpez, E., Daz, G., Ruiz, E., Castro, M. y Peire, J.Integrating and Reusing OF Virtual Labs in Open Source LMS. REV 2008 International Conference, 6 pginas en CD-ROM. Organizador: Universidad de Dusseldorf e IAOE. Editor: Michael E. Auer y Reinhard Langmann, ISBN: 978-3-89958352-2, 23 al 25 de Junio de 2008, Dusseldorf (Alemania). Sancristobal, E., Martn, S., Gil, R., Pastor, R., Garcia-Zubia, J., Ordua, P., Trermio, G., Pesquera, A. Martinez-mediano, C., Diaz, G. Harward, J. y Castro, M. Integration of Virtual Labs in an Open system Management Module. REV 2009 International Conference, 7 pginas en CD-ROM. Organizador: Universidad de Bridgerport e IAOE. Editor: Michael E. Auer navarum Gupta y Jani Pallis, ISBN: 978-3-89958-480-6, 22 al 25 de Junio de 2009, Bridgerport (USA). Tambin se han publicado artculos relativos a esta tesis en los congresos: Interactive Computer Aided Learning (ICL). Celebrados en Villach (Austria) en los aos 2008 y 2009, International Conference on Interactive Mobile and Computer Aided Leraning (IMCL). Celebrado en Amman, (Jordania). 15-19 Abril del 2008 Estancias Estancia en el Center for Educational Computing Initiatives (CECI). Massachusetts Institute of Technology (MIT). Desde 28 de mayo 2009 hasta el 30 de Junio 2009

214

CAPTULO 11.
[ADL, 2009]

BIBLIOGRAFA
Aprendizaje Distribuido Avanzado, http://www.adlnet.gov/Pages/Default.aspx (Accedido el 10 de Diciembre de 2009)

[AICC, 2009]

Aviation Industry computer-based training committee http://www.aicc.org/ (Accedido el 11 de Diciembre de 2009)

[Alamo, 2002]

J. A. Del Alamo, L. Brooks, C. McLean, J. Hardison, G. Mishuris, V. Chang, and L. Hui, "Educational Experiments with an Online Microelectronics Laboratory", ICEE, Manchester (UK), 2002.

[Alamo, 2003]

J. A. Del Alamo, L. Brooks, C. McLean, J. Hardison, G. Mishuris, V. Chang, and L. Hui, MIT Microelectronics WebLab, chapter in T. Fjeldly and M. Shur, Eds., Lab on the Web Running Real Electronics Experiments via the Internet, Wiley-IEEE, 2003, pp. 49-87.

[Anido, 2002]

L. Anido. Traduccin del estndar LOM, http://www.gist.uvigo.es/~lanido/LOMes/ (Accedido el 10 de Diciembre de 2009)

[AOLserver, 2009]

Sitio Web de American Online Server, http://www.aolserver.com/ (Accedido el 20 de Diciembre de 2009)

[Apache, 2009]

Sitio Web de Apache, http://www.apache.org/ (Accedido el 20 de Diciembre de 2009)

[ARIADNE, 2009]

Fundacin ARIADNE, http://www.ariadne-eu.org/ (Accedido el 11 de Diciembre de 2009)

[Auer, 2008]

M. E. Auer, A. Y. Al-Zoubi ynd Danilo Garbi Zutin. Design and Implementation of Mobile Clients for Remote Labs Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2008. Dussedorf (Alemania).

[Berg, 2009]

A. Berg y M. Korcuska. Sakai Courseware Management: A comprehensive and pragmatic guide to using, managing, and maintaining Sakai in the real world. PACKT Publishing, 2009.

[Blackboard, 2009]

Documentacin de Blackboard https://behind.blackboard.com/s/student/refcenter/docs/browse.Bb?pid=0&rid=1&dt=B2,DL,TU , (Accedido el 20 de Diciembre de 2009)

[Blackboard, 2009]

Sitio Web de Blackboard, http://www.blackboard.com/ (Accedido el 20 de Diciembre de 2009)

215

[Bchner, 2008]

A. Bchner. Moodle Administration. Ed. PACK Publishing, 2008.

[Caeiro, 2004]

M. Caeiro, M. Llamas, L. Anido. E-Learning Patterns: an Approach to Facilitate the Design of E-Learning Materials. RIBIE. Monterrey, Mxico, Octubre 2004

[Caeiro, 2007]

Tesis de M. Caeiro. Contribuciones a los Lenguajes de Modelado Educativo. Departamento de Enxeera Telemtica E.T.S.E. de Telecomunicacin. Universidad de Vigo, 2007.

[Chappell, 2004]

D. A. Chappell. Enterprise Service Bus: Theory in Practice. Ed. OReilly Media, 2004.

[CINDETEC, 2009]

Centro de Innovacin y Desarrollo Tecnolgico, UNED. www.innova.uned.es (Accedido el 20 de Diciembre de 2009)

[Claroline, 2009]

Sitio web de Claroline http://www.claroline.net/ (Accedido el 20 de Diciembre de 2009)

[CNICE-MEC, 2009]

CNICE-MEC. Informe: Uso de estndares aplicados a las TIC http://ares.cnice.mec.es/informes/16/contenido/indice.htm (Accedido el 22 de Diciembre de 2009)

[Codeproject, 2009]

Tutorial de ActiveX. http://www.codeproject.com/KB/COM/CompleteActiveX.aspx (Accedido el 23 de Diciembre de 2009)

[Covadonda, 2009]

L.A. Covadonga y M. Matesanz. Las plataformas de aprendizaje: del mito a la realidad. Ed. Biblioteca Nueva, 2009.

[Croy, 2009]

M. Croy y R. Smelser. Informe realizado por el comit de evaluacin de North Caroline http://www.lmseval.uncc.edu/index.php?option=com_docman&task=doc_download&gid=3 9 (Accedido el 20 de Febrero de 2010).

[Curioso, 2007]

A. Curioso. Ajax with PHP 5. Ed. OReilly Media, 2007.

[Davis, 2009]

J. Davis. Open Source SOA. Ed. Manning, 2009.

[Dieec, 2009]

Karnaugh. http://meteo.ieec.uned.es/www_Usumeteo1/HTM/Karnaugh%20inicio.htm , (Accedido el 23 de Diciembre de 2009)

[Dez, 2008]

D. Dez, I. Aedo, P. Daz. Una Experiencia de Uso de Software Educativo en Asignaturas de Programacin de Computadores. Simposio Internacional de Informtica Educativa (SIIE), Salamanca, 1-3 de Octubre 2008.

[dotLRN, 2009]

Sitio Web de .LRN, http://dotlrn.org/ (Accedido el 20 de Diciembre de 2009)

216

[Dublin, 2009]

Sitio Web de Dublin core, http://dublincore.org/ (Accedido el 12 de Diciembre de 2009)

[Edugarage, 2009]

Edugarage: documentacin general de Blackboard, informacin de desarrollo sobre Blackboard. http://www.edugarage.com/ (Accedido el 20 de Diciembre de 2009)

[Elmaghraby, 1968]

S. E. Elmaghraby. "The Role of Modeling in I. E. Design", The Journal of Industrial Engineering, vol. XIX, nm. 6, junio,1968.

[Erl, 2008]

T. Erl, SOA: Principles of Service Design, Ed. Prentice Hall (Pearson Education), 2008.

[Etxebarria, 2003]

Tesis doctoral de A. Etxebarria. Control y Monitorizacin remota de Circuitos Electrnicos Configurables mediante navegadores HTTP. Universidad del Pas Vasco, 2003.

[Fallon, 2003]

C. Fallon y S. Brown. E-learning Standards: A guide to purchasing, developing and deploying standards-conformant e-learning. Ed. ST. Lucie Press, 2003

[Fielding, 2000]

Tesis Doctoral de R. T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, 2000 (USA).

[Fisquiweb, 2009]

FISQUIWEB, pgina Web dedicada al estudio de la fsica y qumica (laboratorios Web, apuntes de la asignatura) http://web.educastur.princast.es/proyectos/fisquiweb/index.htm (Accedido el 22 de Diciembre de 2009)

[Flash, 2009]

Informacin sobre Plataforma Flash. http://www.adobe.com/es/flashplatform/ (Accedido el 22 de Diciembre de 2009)

[Fontela, 2009]

J. Fontela, M. Caeiro, M. Llamas, L. Anido. Reserve OAuth: A solution to Achive delegated Authorizations in Single Sign-on e-leraning System. Computer & Security, Ed. ELSEVIER, 2009.

[Fuller, 1962]

R. B. Fuller. Education automation. Freeing the Scholar to Return to his Studies. Ed. Southern Illinois University Press, 1962.

[Garca-Zubia, 2007]

J. Garca-Zubia y L. Gomes. Advances on remote laboratorios and e-learning experiences. Ed. Universidad de Deusto, 2007.

[Garca-Zubia, 2008]

J. Garca-Zubia, U. Hernndez, I. Angulo and P. Ordua. Remote Laboratories based on LXI. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2008. Dussedorf (Alemania).

[Garca-Zubia, 2009]

J. Garca-Zubia, D. Lpez-de-Ipia, P. Ordua. Addressing Software Impact in the Design of Remote Laboratories, IEEE Transactions on Industrial Electronics, vol. 56, no. 12, pp. 4757-4767, Diciembre 2009.

217

[Garret, 2005]

J.

J.

Garret.

Ajax:

New

Approach

to

Web

Applications

http://www.adaptivepath.com/ideas/essays/archives/000385.php Diciembre de 2009)

(Accedido el 22 de

[Gerantabee, 2009]

F. Gerantabee, Aquent Creative Team, AGI Creative Team. Flash CS4 Professional Digital Classroom. Ed. Wiley Publishing, 2009.

[GLOBE, 2009]

Global Learning Objects Brokered Exchange, http://globe-info.org/es (Accedido el 12 de Diciembre de 2009)

[Ghner, 2008]

S. Jeschke, Thomas, Richter. User Adaptive Interactive Courses in SCORM Compliant Learning Management Systems. International Conference on Interactive Mobile and Computer Aided Leraning (IMCL), Amman, (Jordania), 15-19 Abril 2008.

[GOLC, 2010]

Global Online Laboratory Consortium, http://www.online-lab.net/ (Accedido el 12 de Febrero de 2010)

[Gomes, 2007]

L. Gomes, F. Coito, A. Costa, L. B. Palma y P. Almeida. Remote Laboratories support within Teaching and Learning Activities. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 24-27 de Junio del 2007. Oporto (Portugal).

[Governor, 2009]

J. Governor, d. Hinchcliffe y D. Nickull. Web 2.0 Architectures. Ed. OReilly, 2009.

[Gravier, 2009]

C. Gravier, J. Fayolle, J. Lardon, y B. Bayard. Fostering Collaborative Remote Laboratories through software reusability, authoritative tools, and Open Source licensing. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2009. Bridgeport, NY (USA).

[Griffiths, 2004]

La aportacin de IMS Learning Design a la creacin de recursos pedaggicos reutilizables. Simposio SPEDEC, Alcal de Henares. 2004.

[Gross, 2006]

C. Gross. Ajax and REST Recipes A Problem-Solution Approach. Ed. Apress, 2006.

[Grout, 2009]

I. Grout y A. C. Rodrigues da Silva. Remote Laboratory Description Language Based On XML. Annual International Conference on Remote Engineering and Virtual

Instrumentation (REV), 22-25 de Junio del 2009. Bridgeport, NY (USA).

[Guralnick, 2008]

D. Guralnick, C. Levy. An Online Environment for Academics and Professionals to Locate Collaborators and Refine Ideas. International Conference on Interactive Mobile and Computer Aided Leraning (IMCL), Amman, (Jordania), 15-19 Abril 2008.

218

[Gustavsson, 2007]

I. Gustavsson, J. Zackrisson, L. Hkansson, I. Claesson y T. Lag. The VISIR project an Open Source Software Initiative for Distributed Online Laboratories. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 2427 de Junio del 2007. Oporto (Portugal).

[Gustavsson, 2008]

I. Gustavsson, J. Zackrisson, J. Strm, K. Nilsson, et al. Telemanipulator for Remote Wiring of Electrical Circuits. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2008. Dussedorf (Alemania).

[Hardison, 2008]

J.L. Hardison, K. DeLong, P. H. Bailey y V. J. Harward .Deploying interactive remote labs using iLab shared architecture. ASEE/IEEE frontiers in education conference. 22-25 de Octubre del 2008, Saratoga Springs, NY (USA).

[Hardward, 2004]

V. J. Harward, J. A. del Alamo, V. S. Choudhary, K. deLong et al. iLab: A Scalable Architecture for Sharing Online Experiments. International Conference on Engineering Education. 16-21 de Octubre del 2004, Gainesville, Florida (USA).

[Hewitt, 2009]

E. Hewitt. Java SOA Cookbook. Ed. OReilly, 2009.

[Hopking, 2009]

Laboratorio Web para la Creacin de Circuitos. http://www.jhu.edu/virtlab/logic/logic.htm (Accedido el 26 de Diciembre de 2009).

[Horton, 2003]

W.Horton y K. Horton. E-Learning tools and technologies: A consumer's guide for trainers, teachers, educators, and instructional designers. Wiley publishing, 2003.

[IEEE, 2009]

Sitio Web del IEEE http://www.ieee.org/portal/site (Accedido el 13 de Diciembre de 2009).

[iLabs, 2010]

Sitio Web del Proyecto iLab. http://icampus.mit.edu/projects/iLabs.shtml (Accedido el 12 de Enero de 2010).

[IMS_LD, 2009]

Estndar IMS Learning Design. http://www.imsglobal.org/learningdesign/ (Accedido el 14 de Diciembre de 2009).

[IMS-CC, 2009]

Estndar

IMS

common

cartridge.

http://www.imsglobal.org/commoncartridge.html

(Accedido el 14 de Diciembre de 2009).

[IMS-CP, 2009]

Estndar IMS content packaging. http://www.imsglobal.org/content/packaging/ (Accedido el 14 de Diciembre de 2009).

[IMS-LIS, 2009]

Especificacin

de

servicios

de

informacin

del

aprendizaje

http://www.imsglobal.org/lis.cfm (Accedido el 14 de Diciembre de 2009).

219

[IMS-LTI, 2009]

Estndar

destinado

la

Interoperabilidad

de

herramientas

de

aprendizaje,

http://www.imsglobal.org/ti/index.html (Accedido el 14 de Diciembre de 2009).

[IMS-QTI, 2009]

Estndar

IMS

Question

&

Test

Interoperability

Specification.

http://www.imsglobal.org/question/ (Accedido el 14 de Diciembre de 2009).

[IMS-SS, 2003]

Estndar de secuenciacin IMS, http://www.imsglobal.org/simplesequencing/index.html (Accedido el 14 de Diciembre de 2009).

[ISA, 2010]

The iLab Shared Architecture https://wikis.mit.edu/confluence/display/ILAB2/Developers (Accedido el 12 de Enero de 2010).

[ITProfessionals, 2009]

B.

Madariaga.

Llega

el

reinado

de

SOA.

Noticia

de

ITProfessionals

www.itprofessionals.es/detalle_noticia.asp?Id=427 (Accedido el 27 de Diciembre de 2009).

[Jacobson, 1999]

I. Jacobson, G. Booch y J. Rumbaugh. The Unified Software Development Process. Addison-Wesley Professional. 1999

[Jacobson, 2005]

I. Jacobson, G. Booch y J. Rumbaugh. The Unified Modeling Language Reference Manual. The Addison-Wesley Object Technology Series, 2 edition, 2005

[Java-Sun-Oracle, 2009]

Informacin sobre Applet de Java. http://java.sun.com/applets/ (Accedido el 23 de Diciembre de 2009)

[Josuttis, 2007]

N.M. Josuttis, SOA in Practice, the art of distributed system design. Ed. OReilly, 2007.

[Juric, 2007]

M. B. Juric, R. Loganathan, P. Sarang y F. Jennings. SOA Approach to Integration: XML, Web services, ESB, and BPEL in real-world SOA projects. Ed. PACK Publishing, 2007.

[Kerberos, 2009]

Kerberos: Protocolo de Autenticacin (MIT), http://web.mit.edu/kerberos/ (Accedido el 29 de Diciembre de 2009)

[Ko, 2004]

C.C. Ko, B. M. Chen y J. Chen. Creating Web-based Laboratories. Ed. Springer, 2004.

[Lerro, 2008]

F. Lerro, S. Marchisio, M. Plano, M. Protano y O. Von Pamel. A remote lab like an educational resource in the teaching of the Physics of electronic devices. International Conference: Interactive Computer Aided Learning, 24-26 de Septiembre del 2008, Villach (Austria).

[LETSI, 2009]

LETSI (Learning-Education-Trainning Systems interoperability) , Proyecto de SCORM 2.0 https://letsi.org/index.php?option=com_content&view=article&id=82&Itemid=95 (Accedido el 30 de Diciembre de 2009) ,

220

[LTSC, 2009]

Learning Object Metadata, http://ltsc.ieee.org/wg12/ (Accedido el 12 de Diciembre de 2009)

[Mahemoff, 2006]

M. Mahemoff. Ajax Design Patterns. Ed. O'Reilly, 2006.

[Marcelo, 2006]

C. Marcelo. Prcticas de e-learning. Editorial Octaedro Andalucia, 2006.

[McMaster, 2008]

MCMaster University. LMS Evaluation Information http://www.ltrc.mcmaster.ca/lmseval/ (Accedido el 20 de Febrero de 2010).

[Microsoft-Activex, 2009]

Microsoft ActiveX. http://www.microsoft.com/protect/terms/activex.aspx (Accedido el 23 de Diciembre de 2009)

[Moodle, 2009]

Sitio Web de Moodle (foros, documentacin), http://moodle.org/ (Accedido el 12 de Diciembre de 2009)

[Morales, 2008]

E. Morales, D. A. Gmez y F. J. Garca. HEODAR: Herramienta para la Evaluacin de Objetos Didcticos de Aprendizaje Reutilizables. Simposio Internacional de Informtica Educativa (SIIE), Salamanca, 1-3 de Octubre 2008.

[Morales, 2008]

J. Morales, O C. Santos, J G. Boticario. Adaptation support in design time through IMSQTI and IMS-LD specications in dotLRN web-based learning environment. 7th OpenACS / .LRN conference, encuentro internacional de usuarios de las plataformas

OpenACS/.LRN, Valencia, das 18 y 19 de noviembre de 2008.

[Morales, 2009]

J. Morales, O C. Santos, J G. Boticario. An Approach to Standard-Based Computer Adaptive Testing. Proceedings of the IEEE international conference on advance learning technology (ICALT 2009): IEEE Computer Society Press.

[Moreno, 2007]

Tesis Doctoral de P. Moreno. Una Aproximacin Documental para la Creacin e Integracin de Juegos Digitales en Entornos Virtuales de Enseanza. Universidad Complutense de Madrid, 2007.

[Muoz-Merino, 2010]

P. J. Muoz-Merino, C. Delgado Kloos, M. Muoz-Organero. Enhancement of Student Learning Through the Use of a Hinting Computer e-Learning System and Comparison With Human Teachers. IEEE Transactions on Education, 2010.

[Murphey, 2008]

T. D. Murphey. Teaching Rigid Body Mechanics Using Student-Created Virtual Environments. IEEE Transactions on Education, Volumen: 51:1, paginas10 16, 2008.

221

[Naef, 2006]

O. Naef. Real laboratory, virtual laboratory or remote laboratory: What is the most efficient way?. Annual International Conference on Remote Engineering and Virtual

Instrumentation (REV), 29-30 de Junio del 2008. Maribor (Eslovenia).

[Nafalski, 2009

A. Nafalski, J. Machotka, Z. Nedic, . Gl, A. Scarino, J. Crichton, I. Gustavsson, et al. Collaborative Learning in Engineering Remote Laboratories. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2009. Bridgeport, NY (USA).

[Notas de Elearning, 2009]

comparativas

evaluaciones

entre

LMS

en

el

mbito

acadmico

http://www.caturani.com/2009/10/8-comparativas-y-evaluaciones-entre-lms-en-el-mbitoacadmico/ (Accedido el 20 de Febrero de 2010).

[Notre-Drame, 2008]

Universidad de Notre Drame. Course Management System Replacement Project http://www.ebuford.com/CMS%20REPORT%20FINAL%20PUBLIC%20REPORT%20V1.p df (Accedido el 20 de Febrero de 2010).

[OASIS-SOA, 2009]

Comit

tcnico

del

consorcio

OASIS

del

modelo

de

referencia

SOA,

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm (Accedido el 30 de Diciembre de 2009)

[OpenACS, 2009]

Sitio Web de Open Architecture Community System, http://openacs.org/ (Accedido el 17 de Diciembre de 2009)

[Ordua, 2007]

P. Ordua. Proyecto fin de carrera. WebLab-Deusto: Implementacin de un Laboratorio Remoto Distribuido Basado en la Web 2.0. Deusto, 2007.

[Pardo, 2009]

A. Pardo y C. Delgado Kloos. Learning environment Combining Web 2.0 technology and problem-based learning in a blended learning environment. International Journal of Continuing Engineering Education and Lifelong Learning, 2009. Volume: 19, Issue: 2/3, Pages: 222-231.

[Pastor, 2006]

Tesis doctoral de R. Pastor. Especificacin Formal de Laboratorios Virtuales y Remotos: Aplicacin a la Ingeniera de Control. Universidad de Educacin a Distancia (UNED), 2006.

[Pastor, 2008]

R. Pastor, et. Blocks Organization for .LRN. 7th OpenACS / .LRN conference, encuentro internacional de usuarios de las plataformas OpenACS/.LRN, Valencia, das 18 y 19 de noviembre de 2008.

222

[Peris, 2008]

L. J. Peris Morillo. Proyecto fin de carrera Sistema integrado para el soporte a la docencia en Espacio de Educacin Superior. Universidad de Castilla la Mancha, Escuela Superior de Informtica. Agosto, 2008.

[Pesquera, 2005]

Arquitectura de OpenACS/dotLRN. Presentacin realizada en la seccin de Innovacin de la UNED, 2005.

[PHP, 2009]

Sitio Web PHP Hypertext Pre-processor, http://php.net/index.php (Accedido el 14 de Diciembre de 2009).

[ProLearn, 2009]

ProLearn, http://www.prolearn-project.org/ (Accedido el 14 de Diciembre de 2009).

[Rademakers, 2009]

T. Rademakers y J. Dirksen. Open Source ESBs in Action: Example Implementations in MULE and ServiceMix. Ed. Manning, 2009.

[Ramboll, 2004]

PLS RAMBOLL. Studies in the Context of the E-learning Initiative: Virtual Models of European Universities. http://www.elearningeuropa.info/extras/pdf/virtual_models.pdf

(Accedido el 14 de Diciembre de 2009).

[RELOAD, 2009]

Pgina web del programa Reload, http://www.reload.ac.uk/ (Accedido el 19 de Diciembre de 2009).

[Repondus, 2009]

Respondus. Programa para la creacin de (Accedido el 14 de Diciembre de 2009).

exmenes, http://www.respondus.com/

[Riccioni, 2008]

A. Riccioni y R. Laschi. Design and implementation of a virtual lab for supporting students in modeling, evaluating and programming secure systems. International Conference: Interactive Computer Aided Learning, 24-26 de Septiembre del 2008, Villach (Austria).

[Richardson, 2007]

L. Richardson y S. Ruby. RESTful Web Services. Ed. OReilly, 2007.

[Rios, 2008]

D. Rios y S. Rios Simulacin. Mtodos y Aplicaciones. Ed. RA-MA, 2 EDICIN, 2008.

[Rodrguez, 1999]

Tesis doctoral de J. B. Rodrguez. Planificacin del Diseo en Entornos de Simulacin para el Aprendizaje a Distancia. Universidad Complutense de Madrid, 1999.

[Rosen, 2008]

M. Rosen, B. Lublinsky, K. T. Smith y M. J. Balcer. Applied SOA, Service-Oriented Architecture and Design Strategies. Ed. Willey Publishing 2008.

[RosenBerg, 2001]

M. RosenBerg. E-Learning: Strategies for Delivering Knowledge in the Digital Age. Ed. McGraw-Hill, 2001.

223

[Rowe, 1963]

A. J. Rowe. "Simulation -A Decision- Aiding Tool", A. I. I. E. Intemational Conference Proceedings, Nueva York, 1963.

[Safont, 2007]

Tesis doctoral de Ll. V. Safont. Propuesta e-learning para Titulaciones de Ingeniera en el Espacio Europeo de Educacin Superior. El Campus Virtual mnimo. Universitat Ramon Llull, 2007.

[Saire, 2008]

Distance learning environment in industrial automation using remotes laboratories, http://www.tecsup.edu.pe/graficos/pdf/noticia/imasi.pdf, (Accedido el 10 de Febrero de 2010).

[Sakai, 2009]

Sitio Web de Sakai, http://sakaiproject.org/ (Accedido el 12 de Diciembre de 2009).

[Sakai, 2009]

Wiki de Sakai. http://confluence.sakaiproject.org (Accedido el 12 de Diciembre de 2009).

[Sancho 2008]

P. Sancho, R. Corral, T. Rivas M. J. Gonzlez, C. Tejedor y A. Chordi. Posibilidades del Laboratorio Virtual en el Aprendizaje y la Evaluacin de Competencias en Microbiologa. Simposio Internacional de Informtica Educativa (SIIE), Salamanca, 1-3 de Octubre 2008.

[Scheucher, 2009]

T. Scheucher, P. H. Bailey, C. Gtl, V. J. Harward. Collaborative Virtual 3D Environment for Internet-accessible Physics Experiments. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2009. Bridgeport, NY (USA).

[SCORM, 2004]

Pgina

Web

inicial

del

Modelo

de

agregacin

de

contenidos,

SCORM

http://www.adlnet.gov/technologies/scorm/default.aspx (Accedido el 14 de Diciembre de 2009).

[SCORM, 2009]

ADL-SCORM. http://www.adlnet.gov/Pages/Default.aspx (Accedido el 14 de Diciembre de 2009).

[Shannon, 1988]

R. E. Shannon. Simulacin de sistemas: diseo, desarrollo e implementacin, Ed. Trillas, 1988.

[Sibees-RCSim, 2009]

Simulador de circuitos resistivos. http://www.sibees.com/rcsim.php (Accedido el 29 de Diciembre de 2009).

[Sibees-VLabQ, 2009]

Simulador de prcticas de qumica. http://www.sibees.com/vlabq.php (Accedido el 29 de Diciembre de 2009).

[Sloodle, 2010]

Sitio Web de Sloodle, http://www.sloodle.org/moodle/ (Accedido el 24 de Febrero de 2010).

224

[Smithers, 2009]

M. Smithers. Public LMS Evaluations, http://www.masmithers.com/2009/09/20/public-lmsevaluations/, (Accedido el 20 de Febrero de 2010).

[SOAHowto, 2009]

Invoking

Secured

Services

(https)

from

Oracle

BPEL el

http://soa30 de

howto.blogspot.com/2008/01/invoking-secured-services.html Diciembre de 2009).

(Accedido

[Soumare, 2009]

H. Soumare, R. Shroff, J. L. Hardison, J. A. del Alamo, V. J. Harward, P. H. Bailey y K. DeLong. A Versatile Internet-Accessible Electronics Workbench with Troubleshooting Capabilities. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2009. Bridgeport, NY (USA).

[TCL, 2009]

Tool Command Language, http://www.tcl.tk/, (Accedido el 14 de Diciembre de 2009).

[Torrente, 2009]

J. Torrente, P. Moreno-Ger, I. Martnez-Ortiz, B. Fernndez-Manjn. Integration and Deployment of Educational Games in e-Learning Environments: The Learning Object Model Meets Educational Gaming. Educational Technology & Society, 12 (4), 359371. 2009.

[Tramullas, 2006]

Coordinadores: J. Tramullas y P. Garrido. Software libre para Servicios de Informacin Digital. Ed. Pearson Educacin, 2006.

[UC, 2008]

University of Canterbury, New Zealand. Reviewing the Universitys Learning Management System, http://uctl.canterbury.ac.nz/learn-moodle/review-process-and-documentation

(Accedido el 20 de Febrero de 2010).

[Villasevil, 2009]

Tesis doctoral de F. J. Villasevil. Diseo y Aplicacin de una Metodologa Docente Adaptada al Marco del EEES para Ingeniera con Soporte Multimedia en una Plataforma Virtual. Universidad de Educacin a Distancia (UNED), 2009.

[VISIR, 2009]

Virtual Instrument Systems in Reality. http://openlabs.bth.se/electronics/ (Accedido el 19 de Diciembre de 2009).

[W3-SOAP, 2010]

Recomendacin W3C de SOAP 1.2 http://www.w3.org/TR/soap12-part1/#intro (Accedido el 2 de Enero de 2010).

[Wei-Fan, 2008]

C. Wei-Fan; W. Wen-Hsiung; S. Te-Jen . Assessing Virtual Laboratories in a Digital-Filter Design Course: An Experimental Study. IEEE Transactions on Education, Volumen: 51:1, paginas10 16, 2008.

[William, 2008]

H. William Rice IV. Moodle 1.9 E-learning course Development. Ed. PACK Publishing, 2008.

225

[Williams, 2009]

I. Williams. XSLT and Xpath Transforming XML Documents and Data. Ed. Wrox, 2009.

[Zutin, 2008]

D.G. Zutin, M. E. Auer, J.F. Bocanegra, E.R.Lpez, A.C.B. Martins, J.A.Ortega, A. Peste. TCP/IP Communication between Server and Client in Multi User Remote Lab Applications. Annual International Conference on Remote Engineering and Virtual Instrumentation (REV), 22-25 de Junio del 2008. Dussedorf (Alemania).

226

ANEXO 1. CONTENIDO DEL CD-ROM

Moodle. Contiene la version 1.0 del mdulo para aadir laboratorios como actividad de un curso. Laboratories. Contiene lo ficheros php que sern llamados desde el bloque administrador de Moodle. Settings. Contiene los ficheros aadidos y modificados para mostrar las opciones dentro del bloque de administracin de Moodle. Wlab. Mdulo de Moodle que se ha creado. Paquetes dotLRN. Paquetes creados para la integrar laboratorios en dotLRN. dotlrn-entornolaboratorio. Applet de entorno laboratorio. entorno-laboratorio. Paquete entorno laboratorio. Creacin del grupo laboratorios y gestin. entornolaboratorio-portlet. Portlet de entorno laboratorio labs. Nueva versin, que se ha creado del paquete entorno-laboratorio Tesis en PDF. Contiene la tesis en formato PDF.

227

228