2. Cliente .LRN:
El cliente web debe ser ejecutado desde el navegador en todas las m´aquinas destinadas a la colaboraci´on.
Tanto el estudiante y profesor que quieren realizar colaboraci´on debe estar inscritos en un curso virtual de aprendizaje en la plataforma .LRN.
Las m´aquinas deben tener los requisitos m´ınimos de hardware y software, como tarjeta de video, tarjeta de sonido, maquina virtual java, plugins de video, audio.
Lo ideal ser´ıa que un alumno tenga su m´aquina, esto no es un requisito.
El profesor debe tener una cuenta de administrador para brindar permisos sobre los archi- vos compartidos en cada curso.
3.1.4. Modelo de referencia del sistema de aprendizaje interactivo.
Las pizarras digitales interactivas permiten crear un nuevo escenario de aprendizaje interactivo tanto en el aula como en espacios virtuales de aprendizaje. La informaci´on desplegada en las pizarras puede ser optimizada por los recursos computacionales y utilizar los espacios virtuales para obtener mayor audiencia y retroalimentaci´on por parte de estudiantes.
En un espacio o aula f´ısica el estudiante puede interactuar con los elementos proyectados en la pizarra digital pero la plataforma LMS tiene la capacidad para que un profesor pueda interactuar colaborati- vamente con el estudiante, compartir informaci´on de los contenidos generados en clase en la pizarra digital interactiva y acoplando su ense˜nanza al espacio virtual para ser accedida desde puntos distantes. Este modelo de referencia de actividades de aprendizaje interactivo a trav´es de la pizarra digital en la plataforma .LRN se basa en un entorno de aprendizaje con dos caracter´ısticas fundamentales: ubicuidad ya que podemos acceder a los contenidos del curso y del sal´on de clase a trav´es de una plataforma LMS y servidor multimedia, e interacci´on, para que el estudiante pueda obtener retroalimentaci´on de la informaci´on generada en clase con la pizarra digital interactiva por parte de sus compa˜neros y profesores.
La figura 3.2, ilustra el entorno tecnol´ogico apropiado para integrar actividades de aprendizaje inter- activo a trav´es de la pizarra digital en la plataforma .LRN. En la capa 1 (interfaz de dispositivos) se encuentran PC y Tablet PCs, Laptop, SmartPhones con capacidad de navegaci´on web y java, en la se- gunda capa (Escenario de aprendizaje) se localiza el espacio f´ısicos donde se lleva a cabo la actividad con la pizarra digital interactiva de bajo costo y en la tercera capa (Internet) se encuentra el servidor de contenidos multimedia y de LMS en nuestro caso .LRN.
3.2.
Arquitectura de OpenACS
La herramienta de OpenACS se ejecuta en AOLserver1y utiliza una base de datos relacional de Oracle o PostgreSQL (de c´odigo abierto). AOLserver se utiliza en todo el mundo para ejecutar aplicaciones web din´amicas escalables y exigentes.
1
AOLserver, servidor web de America Online de c´odigo abierto. AOLserver tiene procesamiento multihilo, soporte para Tcl, y se usa para sitios web din´amicos de gran tama˜no.
Figura 3.1: Modelo de referencia del sistema de aprendizaje.(Fuente propia)
La arquitectura de openACS se basa en componentes [60]. Esto permite formar una aplicaci´on espec´ıfica a partir de la uni´on de diferentes componentes personalizando el portal. Los componentes en los que se basa su funcionamiento son componentes dise˜nados y probados en entornos de alta demanda, est´an disponibles gratuitamente para su descarga desde Internet bajo licencia libre y se describen en este aparte. Estos componentes son:
GNU / Linux:El sistema operativo de c´odigo abierto m´as conocido, GNU / Linux es un servidor de clase empresarial altamente probado, estable y escalable en extremo. Adem´as, tiene amplia documentaci´on disponible y un gran n´umero de desarrolladores alrededor del mundo. GNU / Linux se est´a ejecutando actualmente sitios como Amazon.com, eBay y Orbitz.com. Sin embargo OpenACS tambi´en se puede ejecutar en Windows y otras variantes de UNIX y Linux.
AOLserver[61]: Nivel intermedio de OpenACS. Es el servidor de aplicaciones web de alto rendimien- to de AOLserver es similar en alcance a los servidores, tales como BEA WebLogic, IBM WebSphere y Tomcat de Apache. Las caracter´ısticas que lo convierten en un servidor fuerte son:
Arquitectura multi-hilo para obtener un rendimiento muy eficiente en ambientes de alta deman- da.
3.2. Arquitectura de OpenACS
Figura 3.2: Arquitectura de openACS. (Fuente propia)
Conexiones de base de datos para una r´apida conectividad, bases de datos disponibles. y un lenguaje de scripting embebido (TCL) para el r´apido desarrollo de la l´ogica de negocio. AOLserver est´a disponible gratuitamente en AOLserver.com.
PostgreSQL:PostgreSQL es la base de datos relacional de c´odigo abierto m´as avanzada disponible y fue la primera base de datos para ser totalmente compatible con ACID2. Comenz´o como un proyecto en la Universidad de California en Berkeley, PostgreSQL tiene estado en desarrollo durante m´as de 30 a˜nos. Hasta hace poco era la base de datos de Source Forge, el repositorio principal de los proyectos de c´odigo abierto.
Sistema de paquetes
OpenACS esta conformada por un conjunto de paquetes que se pueden encontrar en los OACS-HOME en subdirectorio de packages. Cada paquete puede contener secuencias de comandos SQL, librer´ıas Tcl y p´aginas visibles, todos los paquetes se estructuran utilizando el Modelo-Vista- Controlador (MVC).
Otros paquetes disponibles incluyen:
Calendario, la creaci´on de blog, cuestionarios de evaluaci´on, de agregaci´on de noticias, wikis, galer´ıas de fotos, soporte RSS, XML RPC, SOAP y apoyo a muchos m´as.
B´asicamente existen tres tipos de paquetes:
• Paquetes del Core: se requieren para que OpenACS funcione. Incluyen el Kernel, el gestor de paquetes, utilidades para la administraci´on de usuarios, el Sitemap, el sistema de plan- tillas que separa claramente la l´ogica de negocio de la l´ogica de presentaci´on, y un sistema de mensajer´ıa Back - End.
2
ACID (atomicity, consistency, isolation, durability), conjunto de propiedades que garantizan que las operaciones de base de datos se procesen de forma fiable.
• Servicios: son paquetes de l´ogica reusable, no dependen de otros paquetes y no requieren interfaz de usuario.
• Aplicaciones: tienen una interfaz de usuario y su c´odigo est´a claramente dividido en la l´ogica de aplicaci´on y la l´ogica de presentaci´on.
Adem´as, OpenACS tiene el gestor de paquetes APM (ACS Package Manager)[62], una he- rramienta que ayuda al administrador a manejar los diferentes paquetes, instalar o desinstalar, actualizar y administrar las dependencias entre paquetes.
Contenido del repositorio
El Repositorio de Contenidos (CR) es una aplicaci´on del servicio central que puede ser utilizado por otras aplicaciones para gestionar su contenido [63]. El desarrollador debe definir y declarar las interacciones con el repositorio de contenido. Las principales caracter´ısticas del repositorio de contenido son las siguientes:
• Guarda cualquier tipo de informaci´on (archivos, datos, texto).
• Revisi´on de control, lo que significa que todas las adiciones y los cambios posteriores de una aplicaci´on est´an registradas, por ejemplo, agregar una nueva versi´on sobre el conteni- do.
• Capacidad de manejar jerarqu´ıas y estructuras de carpetas, y heredar sus propiedades.
• Tambi´en se encarga de publicar los estados para el contenido que pueda necesitarlo.
• Identificar el contenido a trav´es de definici´on de tipo de contenido.
• Asociar el contenido con aplicaciones externas.
• Guardar las plantillas que se usar´an cuando se muestran los tipos de contenido espec´ıficos.
• Crear relaciones entre los elementos del repositorio de contenidos u objetos de base de datos externa.
• Motor de b´usqueda integrado para exponer de forma autom´atica el contenido. El proceso de una aplicaci´on para utilizar el repositorio de contenido es:
1. Definir la estructura de base de datos que la aplicaci´on.
2. Utilizar la API estandarizada (para agregar, editar, eliminar, presentar) para crear secuen- cias de comandos para la permitir el CR de la aplicaci´on.
La l´ogica de CR se almacena en la base de datos de funciones y disparadores, pero lo hace el API Tcl que une todas las llamadas base de datos implicadas y hace sencillo para los desarrolladores crear aplicaciones que utilizan el CR.
Modelos de datos de OpenACS y objetos del sistema Proceso de las peticiones
Usualmente modelamos la informaci´on de un objeto y de sus atributos para que la apli- caci´on pueda guardar y manipular y definir un conjunto de tablas SQL, pero adem´as de esto el desarrollador en OpenACS de una aplicaci´on debe hacer un conjunto acciones extra [64] :
3.2. Arquitectura de OpenACS
Facilitar permisos del sistema, para hacer seguimiento de quien tiene permitido modificar las tablas y tener un f´acil control de esto para los tcl.
Cada objeto tiene un atributo llamado context-id que proporciona una manera f´acil de establecer permisos y el “alcance” de un objeto, adem´as debe estar contenido en acs-objetc, con el fin de aprovechar los atributos utilizando el sistema de objetos.
OpenACS implementa un procesador de peticiones[65] cuyo objetivo es procesar la pila de peticiones que los usuarios env´ıan para acceder a los servicios o aplicaciones contenidas en el servidor web. Debido a su complejidad se manejan en un Procesador de Peticiones (RP) el cual maneja cada una de las peticiones. La figura 3.2.1, muestra un diagrama de secuencia para el manejo de las peticiones [66]de openACS.
La descripci´on de los elementos y la interacci´on del sistema de describe a continuaci´on:
• Mapa del sitio:El RP mapea la URL a un archivo f´ısico buscando sobre los datos del sitio y de instancias de la aplicaci´on.
• La autenticaci´on:El RP examina informaci´on de la sesi´on enviada por el navegador del cliente utilizando cookies.
• La autorizaci´on:Una vez el usuario se ha autentificado, el RP verifica si el usuario tiene el permiso de acceso para el file/object pedido. El acceso es gestionado por el sistema de permisos.
• Procesar la URL:El RP busca el archivo a ser servido. Dependiendo de la extensi´on, el archivo podr´ıa servirse directamente (.html) o enviarlo al sistema de plantilla (.adp) o al int´erprete del tcl.
El sistema de permisos
El sistema de permisos de OpenACS [67] permite a dise˜nadores y administradores establecer m´etodos de control de accesos a nivel del objeto, es decir, cualquier paquete que utilice este sistema de objetos puede controlarse a trav´es de c´odigo simple PL/SQL o interfaz de Tcl. El sistema de permisos maneja un modelo de datos que permite mediante scripts verificar permisos usando una simple llamada al API. El manejo del acceso para cada uno de estos usuarios y objetos seria tedioso para el administrador o dise˜nador sino se contara con los siguientes mecanismos auxiliares para hacer esto m´as f´acil: Primero, el sistema de Grupos les permite a los usuarios agruparse de maneras flexibles. Segundo, el modelo del objeto define una noci´on de “contexto del objeto” que permite a las aplicaciones agrupar objetos en dominios de seguridad m´as grandes.
• Sistema de grupos: definir agrupaciones simples de usuarios. Introduce una nueva abstrac- ci´on llamada, “party”, con el fin realizar nuevas asociaciones entre grupos por ejemplo de que todos los usuario del grupo A puedan pertenecer al grupo B. Este modelo de datos de los grupos es recursivo. El hecho que se mapeen las parties como una persona o un grupo tiene mucho poder, permiti´endonos modelar agrupaciones jer´arquicas complejas de personas y grupos.
• Sistema de objetos: Utiliza el contexto similarmente como otro objeto que representa el dominio de seguridad al que el objeto pertenece. Por consiguiente, si un objeto A no tiene ning´un permiso expl´ıcitamente, entonces el sistema mirar´a la columna del “context id” en el “acs objects” y verificar´a los permisos del objeto en el contexto de all´ı.
• Permisos: Este modelo de datos es un mapeo entre privilegios, parties y objetos. En Ope- nACS se implementan los permisos sobre objetos para realizar operaciones de lectura, escritura, creaci´on, eliminaci´on o administraci´on. La tabla de privilegios est´a organizada jer´arquicamente para definir en conjunto una serie de privilegios y combinarlos en una sola entidad que los acumule de manera que podamos aplicarlos en combo a cada usuario.
El sistema de plantillas
El Sistema de Plantillas [68] (ATS) se utiliza con el fin de permitir a los dise˜nadores tener diferenciada la l´ogica de la aplicaci´on de la l´ogica de dise˜no. Se quiere separar toda la l´ogica relacionada con la manipulaci´on la base de datos y otros datos del estado del uso en un lugar, y toda la l´ogica relacionada con la presentaci´on en otro lugar. Esto facilita una personalizaci´on m´as ´agil e independiente al dise˜nador y actualizaciones m´as f´aciles.
En ATS, se escriben dos archivos del sistema para cada p´agina visible al usuario. Uno es un archivo plano .tcl y el otro es un archivo especial de .adp Los archivos .tcl ejecutan un script que prepara un conjunto de par´ametros name/value que se conocen como las fuentes de datos. Estas fuentes de datos son generalmente el resultado de los ficheros Tcl y/o consultas a la base de datos o alguna combinaci´on de estas.
3.2. Arquitectura de OpenACS
donde los valores se substituyen adentro de las caracter´ısticas configuradas por el archivo del tcl.
Internacionalizaci´on/Localizaci´onEl texto visible para el usuario en el c´odigo de un paquete internacionalizado [69] est´a codificado como “claves del mensaje.” Las claves de mensaje co- rresponden a un cat´alogo de mensajes, que contiene las versiones del texto para cada idioma disponible adem´as la internacionalizaci´on afecta otras funciones como la escritura de la fecha en la base de datos seg´un su localizaci´on.
3.2.1. .LRN
.LRN usa el framework orientado a objetos de OpenACS para la creaci´on de aplicaciones web, en el cual viene los modulos de gesti´on user/group utilizados por el sistema para gestionar grupos de usuarios, con el fin de habilitar la autenticaci´on, persistencia, y plantillas mencionadas en la arquitectura de OpenACS anteriormente, de esta manera cuando el usuario se autentifica en una p´agina, la petici´on es procesada por user/group, para autorizar o no la petici´on. Si se autoriza, la p´agina es personalizada usando al sistema de plantillas y el modelo de datos del usuario.
El sistema de plantillas (ATS) ensambla la p´agina que solicita el usuario con los diferentes elementos de dise˜no contenidas en el servidor, como por ejemplo pueden montar aplicaciones diferentes una aplicaci´on de calendario o una actividad para el horario de clase y cada elemento se maneja manera similar, con un API estandar.
El sistema de permisos permite a administradores dar los atributos a los content u objetos del sistema (lectura, escritura administraci´on).
El modelo de datos est´andar de OpenACS para el usuario permite una amplia personalizaci´on para todas las aplicaciones de un sitio particular. Para administradores, la gesti´on se realiza con un solo sistema de plantillas, una gesti´on de paquetes y un sistema de permisos en todas las aplicaciones.
Portlet
Los portlet generan el interfaz visual para los portales de .LRN, tomando para ello los paquetes del repositorio de contenido y permitiendo que entreguen funcionalidad personalizada basada en las aplicaciones de OpenACS. Figura muestra un diagrama de clase del dise˜no de un portlet.
Portal de usuario
.LRN se construye con el framework de OpenACS, hereda todas las funcionalidades de OpenACS, modularidad y caracter´ısticas. El sistema adapta el portal a cada usuario recogiendo la informaci´on sobre los cursos y comunidades en los que el estudiante, profesor, administrador u otro est´an matriculados, y qu´e aplicaciones de estos cursos y comunidades est´an usando. La apariencia de este portal puede ser personalizada por el administrador del curso a trav´es de una p´agina de configuraci´on sin necesidad de modificar el c´odigo fuente del LMS.
Un paquete puede ser el calendario, agenta, eventos, preguntas frecuentes etc. La vista de un pa- quete se llama portlet, de manera que podemos usar los portlets para personalizar nuestro portal.
Comunidades
Los usuarios de una comunidad pueden pertenecer sin distinci´on a varios cursos necesarios para cumplir sus objetivos de aprendizaje, conformando grupos de clase o agrupaciones de estudiantes.
Las comunidades podr´ıan representar los grupos de inter´es especiales, o proyectos o simplemente recolecciones sociales.
.LRN se apoya en el scoping para cada aplicaci´on para que cada course/community pue- den tener sus propias aplicaciones fijas, plantillas y permisos y usa el concepto subsites que separa los contextos entre diferentes tipos de comunidades (clases y clubes) para tener su propia estructura de permisos.
La figura 3.5 muestra un diagrama de clases que relacionan el departamento con la cla- se subject. “los departamentos” describen la estructura estandar dentro de la instituci´on, “el Subjetc” contiene informaci´on que repite en los diferentes casos en una “Class” Una Clase especifica personas y sus roles, fechas de entrada y salida, y otros atributos que son espec´ıfico a ese caso.
Usuarios
OpenACS puede soportar complejas jerarqu´ıas del usuario definiendo “parties” [70] como pue- de ser: “los usuarios” identificados por un correo electr´onico distinto o una persona con el dife- rente nombre y apellido o un “grupo” que de pronto pueden ser de los anteriores grupos u otros grupos. Estas relaciones se muestran en Figura 3.6 Con esta arquitectura de .LRN los usuarios pueden tener m´as de un rol en particular determinando lo que al usuario se le permite hacer. La clase .LRN es una subclass de las “parties” de OpenACS con el “rol” como un atributo, este puede tomar los valores como el Estudiante, Curso Assistant, Instructor, etc.