PROPUESTA DE UN PROTOTIPO DE ACCESO REMOTO VIRTUAL AL

PROYECTO “GLObal Robotic-telescopes Intelligent Array”.

Director:

Roberto Ferro

Estudiante:

Diego Felipe Soto Conde

Codigo:

20121195014

Maestría Ciencias de la Información y las Comunicaciones

Universidad Distrital Francisco Jose de Caldas

2017

Índice general

1. Introducción 9

2. Estudio del Conocimiento 11

2.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Alcance y Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2. Limitación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Estado del Arte 15

4. Marco Referencial 18

4.1. Laboratorios Virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2. Tipos Generales de Laboratorios Virtuales . . . . . . . . . . . . . . . . . 19

4.2.1. Laboratorio Virtuales Software . . . . . . . . . . . . . . . . . . . 19

4.2.2. Laboratorios Virtuales Web: . . . . . . . . . . . . . . . . . . . . 20

4.2.3. Realidad Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.4. Laboratorios Remotos . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.5. Laboratorios Electrónicos . . . . . . . . . . . . . . . . . . . . . 20

2

4.3. Second Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4. Opensim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1. OpemSim para la Educación . . . . . . . . . . . . . . . . . . . 22

4.5. E-Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6. Web 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7. Proyecto GLORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7.1. ¿Quién puede acceder a GLORIA? . . . . . . . . . . . . . . . . . 26

4.7.2. ¿Qué servicios ofrecerá GLORIA? . . . . . . . . . . . . . . . . . 26

4.7.3. ¿Cómo GLORIA afrontará a los desafíos? . . . . . . . . . . . . . 26

4.8. Sistema Gloria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.8.1. Arquitectura de Red . . . . . . . . . . . . . . . . . . . . . . . . 29

4.8.2. Programador Red de Telescopio . . . . . . . . . . . . . . . . . . 30

4.9. Gestión de los Telescopios . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.9.1. Arquitectura RTS . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.9.2. Registro RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.9.3. Administración de Usuarios y el Sitio Web . . . . . . . . . . . . 34

4.9.4. Autenticación del usuario . . . . . . . . . . . . . . . . . . . . . 34

4.9.5. Herramienta de Creación . . . . . . . . . . . . . . . . . . . . . . 36

4.9.6. Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.9.7. Karma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.9.8. Resultados Gloria . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5. Desarrollo, Analisis y Diseño del Prototipo 42

5.1. Puntos de Vista Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1. Punto de Vista de Organización . . . . . . . . . . . . . . . . . . 45

5.1.2. Punto de Vista Cooperación de Actor . . . . . . . . . . . . . . . 48

5.1.3. Punto de Vista de Función de Negocio . . . . . . . . . . . . . . . 50

5.1.4. Punto de Vista de Proceso de Negocio . . . . . . . . . . . . . . . 52

5.1.5. Punto de Vista de Cooperación de Proceso de Negocio . . . . . . 54

3

5.1.6. Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . 56

5.1.7. Punto de Vista de Comportamiento de la Aplicación . . . . . . . 58

5.1.8. Punto de Vista de Cooperacion de Aplicación . . . . . . . . . . . 60

5.1.9. Punto de Vista de Estructura de Aplicación . . . . . . . . . . . . 62

5.1.10. Punto de Vista de Uso de Aplicación . . . . . . . . . . . . . . . . 64

5.1.11. Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . 66

5.1.12. Punto de Vista de Uso de Infraestructura . . . . . . . . . . . . . . 68

5.1.13. Punto de Vista de Estructura de Información . . . . . . . . . . . 70

5.1.14. Punto de Vista de Realización del Servicio . . . . . . . . . . . . 72

5.1.15. Punto de Vista de Proceso de Capas . . . . . . . . . . . . . . . . 74

5.1.16. Punto de Vista de Stakeholder . . . . . . . . . . . . . . . . . . . 75

5.1.17. Punto de Vista de Realización de Objetivos . . . . . . . . . . . . . 77

5.1.18. Punto de Vista de Contribución . . . . . . . . . . . . . . . . . . 79

5.1.19. Punto de Vista de Principios . . . . . . . . . . . . . . . . . . . . . 81

5.1.20. Punto de Vista de Realización de Requerimientos . . . . . . . . . 83

5.1.21. Punto de Vista de Motivación . . . . . . . . . . . . . . . . . . . 85

5.1.22. Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . 87

5.1.23. Punto de Vista de Migración . . . . . . . . . . . . . . . . . . . . 89

5.1.24. Punto de Vista de Migración e Implantación . . . . . . . . . . . . . 91

5.2. Modelamiento de Patrones del Prototipo Aulas Virtuales 3D . . . . . . . 93

5.2.1. Patron Singleton Aplicado . . . . . . . . . . . . . . . . . . . . . 93

5.2.2. Patron Constructor Aplicado . . . . . . . . . . . . . . . . . . . . 94

5.2.3. Patron Fabrica Abstracta Aplicado . . . . . . . . . . . . . . . . . 95

5.2.4. Patron Fabrica Aplicado . . . . . . . . . . . . . . . . . . . . . . 96

5.2.5. Patron Prototipo Aplicado . . . . . . . . . . . . . . . . . . . . . . 97

5.2.6. Patron Adaptador Aplicado . . . . . . . . . . . . . . . . . . . . . 98

5.3. Montaje y Elaboración del Metaverso . . . . . . . . . . . . . . . . . . . 99

5.4. Modelo TMN-UIT o Modelo OSI . . . . . . . . . . . . . . . . . . . . . . 101

4

5.5. Protocolo de acceso Opem Sim y la Web Semantica (Web 3.0) en el proyecto

GLORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6. Conclusión 107

5

Índice de figuras

4.1. 18 Telescopios de la red Gloria Año 2014 . . . . . . . . . . . . . . . . . . 27

4.2. Sistema Gloria [46] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3. Arquitectura de Red GLORIA [47] . . . . . . . . . . . . . . . . . . . . . 29

4.4. Interfaz Gloria de aplicaciones programadas [47] . . . . . . . . . . . . . 30

4.5. Arquitectura RTS (a) Telescopio Robótico en la red GLORIA (b) [48] . . 32

4.6. Autenticaión del Usuario [50] . . . . . . . . . . . . . . . . . . . . . . . 36

4.7. Herramienta de Autoría GLoria [51] . . . . . . . . . . . . . . . . . . . . . 37

4.8. Las instantáneas de las dos interfaces web de GLORIA. Izquierda: El Sol

como se observa por el telescopio solar de 25 cm en el Observatorio del

Teide. Derecha: La nebulosa M 17 según lo observado por el telescopio

TELMA de 60 cm en la estación BOOTES-2 en Algarrobo Costa.[28] . . 38

4.9. Interacción entre Karma y el modelo económico [52] . . . . . . . . . . . 39

4.10. Experimento Interface Solar TAD . . . . . . . . . . . . . . . . . . . . . . 41

5.1. Laboratorio Practicas Ingenierías . . . . . . . . . . . . . . . . . . . . . . 42

5.2. Laboratorio Virtual WebUdistrital . . . . . . . . . . . . . . . . . . . . . 43

5.3. Comunicación de la Arquitectura WebUdistrital . . . . . . . . . . . . . . 44

5.4. Metamodelo Punto de Vista de la Organización . . . . . . . . . . . . . . 45

5.5. Modelo Punto de Vista de la Organización . . . . . . . . . . . . . . . . . 46

5.6. Metamodelo Punto de Vista Coperación del Actor . . . . . . . . . . . . . 48

5.7. Modelo Punto de Vista Cooperación del Actor . . . . . . . . . . . . . . . 49

5.8. Metamodelo Punto de Vistade Función de Negocio . . . . . . . . . . . . 50

6

5.9. Modelo Punto de Vista de Función de Negocio . . . . . . . . . . . . . . . 51

5.10. Metamodelo Punto de Vista Proceso de Negocio . . . . . . . . . . . . . . 52

5.11. Modelo Punto de Vista Proceso de Negocio . . . . . . . . . . . . . . . . 53

5.12. Metamodelo Punto de Vista Cooperación de Proceso de Negocio . . . . . 54

5.13. Modelo Punto de Vista Proceso Cooperación de Negocio . . . . . . . . . 55

5.14. Metamodelo Punto de Vista de Producto . . . . . . . . . . . . . . . . . . 56

5.15. Modelo Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . 57

5.16. Metamodelo Punto de Vista de Comportamiento de la Aplicación . . . . . 58

5.17. Modelo Punto de Vista de Comportamiento de la Aplicación . . . . . . . 59

5.18. Metamodelo Punto de Comportamiento de Aplicación . . . . . . . . . . . 60

5.19. Modelo Punto de Vista Proceso De Negocio . . . . . . . . . . . . . . . . . 61

5.20. Metamodelo Punto de Vista de Estructura de Aplicación . . . . . . . . . 62

5.21. Modelo Punto de Vista de Estructura de Aplicación . . . . . . . . . . . . 63

5.22. Metamodelo Punto de Vista de Uso de Aplicación . . . . . . . . . . . . . 64

5.23. Modelo Punto de Vista de uso de Aplicación . . . . . . . . . . . . . . . . 65

5.24. Metamodelo Puntos de Vista Proceso de Infrestructura . . . . . . . . . . 66

5.25. Modelo Puntos de Vista Proceso de Infraestructura . . . . . . . . . . . . . 67

5.26. Metamodelo Puntos de Vista Uso de Infraestructura . . . . . . . . . . . . 68

5.27. Modelo Puntos de Vista Proceso de Infraestructura . . . . . . . . . . . . 69

5.28. Metamodelo Puntos de Vista Estructura de Información . . . . . . . . . . 70

5.29. Modelo Punto de Vista Estructura de Información . . . . . . . . . . . . . . 71

5.30. Metamodelo Puntos de Vista Realización del Servicio . . . . . . . . . . . 72

5.31. Modelo Punto de Vista Realización del Servicio . . . . . . . . . . . . . . 73

5.32. Modelo Puntos de Vista de Capas . . . . . . . . . . . . . . . . . . . . . 74

5.33. Metamodelo Punto de Vista de Stakeholder . . . . . . . . . . . . . . . . 75

5.34. Modelo Punto de Vista de Stakeholder . . . . . . . . . . . . . . . . . . . 76

5.35. Metamodelo Punto de Vista Realización de Objetivos . . . . . . . . . . . . 77

5.36. Modelo Punto de Vista Realización de Objetivos . . . . . . . . . . . . . . 78

5.37. Metamodelo Punto de Vista de Contribución . . . . . . . . . . . . . . . . 79

7

5.38. Modelo Punto de Vista Contribución . . . . . . . . . . . . . . . . . . . . 80

5.39. Metamodelo Puntos de Vista de Principios . . . . . . . . . . . . . . . . . . 81

5.40. Modelo Punto de Vista de Principios . . . . . . . . . . . . . . . . . . . . 82

5.41. Metamodelo Punto de Vista de Realización de Requerimientos . . . . . . 83

5.42. Modelo Puntos de Vista de Realización de Requerimientos . . . . . . . . 84

5.43. Metamodelo Punto de Vista Motivación . . . . . . . . . . . . . . . . . . 85

5.44. Modelo Puntos de Vista Motivación . . . . . . . . . . . . . . . . . . . . 86

5.45. Metamodelo Puntos de Vista de Proyecto . . . . . . . . . . . . . . . . . . 87

5.46. Modelo Puntos de Vista Proceso De Negocio . . . . . . . . . . . . . . . 88

5.47. Metamodelo Punto de Vista de Migración . . . . . . . . . . . . . . . . . 89

5.48. Modelo Punto de Vista de Migracion . . . . . . . . . . . . . . . . . . . . 90

5.49. Metamodelo Punto de Vista Migración e Implantación . . . . . . . . . . . 91

5.50. Modelo Punto de Vista de Migración e Implantación . . . . . . . . . . . 92

5.51. Convierte la interface de una clase en otra interface que el cliente espera . 93

5.52. Favorece el ensamble de productos complejos separando creación represen-

tación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.53. Favorece a creación de familia de productos. . . . . . . . . . . . . . . . . 95

5.54. Define una interface para crear un objeto, que de posterga a sus subclases 96

5.55. Especifica la clase de objetos a crear usando una instancia prototípica par

crear nuevos objetos, que de posterga a sus subclases . . . . . . . . . . . . 97

5.56. Define la creación de una sola instancia . . . . . . . . . . . . . . . . . . 98

5.57. Modelo Capas Web Semantica . . . . . . . . . . . . . . . . . . . . . . . 104

8

Capítulo 1

Introducción

El nacimiento del Internet, ha llevado a la ciencia y la investigación a obtener grandes logros,

difundiendo y compartiendo el conocimiento entre los estudiantes de todo el mundo; esto ha

originado canales y nuevas formas de comunicación en la educación, donde la incorporación

de nuevas tecnologías ha logrado que los estudiantes creen grupos de intercambio en el

conocimiento, en espacios colaborativos con las plataformas de educación virtual. El uso de

ambientes educativos virtuales es el mejoramiento de la educación basada en estos sistemas,

que incentivan a tener participación de la comunidad estudiantil en la enseñanza virtual con

espacios como son los laboratorios representados en 3D, utilizando herramientas en Internet

como la web semántica, siendo una web de servicios interpretables e interoperables y las

bondades de OpenSim, donde su servicio es de código abierto que permite crear ambientes

virtuales y uso de múltiples protocolos, para implementar mundos inversivos en Instituciones

de Educación Superior como los mundos virtuales con ambientes del mundo real; buscando

facilitar el desarrollo de tareas que de manera presencial es difícil de lograr debido a razones

geográficas en espacio y tiempo; esto conlleva a estructurar las actividades que constituyen

parte integral de la enseñanza de la ciencia y la ingeniería despertando el interés en estudiar

y proponer un prototipo de aula virtual 3D en astronomía en el acceso a la red de telescopios

del proyecto GLORIA (“GLObal Robotic telescope Intelligent Array”), tipo web 3.0 de

servicio Educativo, donde la web 3.0 es una Web semántica que se caracteriza, de las

9

siguientes maneras: de inteligencia, Sociabilidad, Rapidez, Abierta, Ubicua, de Facilidad,

Distribución, Tridimensional; donde en su desarrollo se creara un prototipo de ambiente

virtual 3D para la Universidad Francisco José de Caldas, con escenarios de laboratorios con

contenidos interactivos y de conexión en tiempo real con la red de telescopios GLORIA

para mostrarles y darles a los estudiantes una visión en la construcción de estos tipos de

proyectos, despertando el interés de la ciencia de los astros. El proyecto GLORIA ha creado

la primera red de telescopios robóticos siendo de uso libre y abierto a la gente común de

todo el mundo con la característica que el tiempo de observación es limitado, los usuarios

deben demostrar sus capacidades para obtener el tiempo de uso, y compiten a través de

puntuación, función de mérito para el acceso.

10

Capítulo 2

Estudio del Conocimiento

2.1. Planteamiento del problema

La comunidad científica ha adoptado y enfatizado diferentes paradigmas, principalmente en

respuesta al costo o el esfuerzo de la tarea investigativa y laboratorios especializados que se

requieren. De esa forma se ha pasado la ciencia empírica a la teórica y posteriormente a las

aproximaciones con simulaciones mediante el uso de mundos virtuales.

Los sistemas de enseñanza basada en Internet, trasladan el entorno a espacios virtuales,

donde se puede enriquecer el proceso de autoaprendizaje; pero para los casos, en donde

es necesaria la realización de actividades y prácticas en laboratorios convencionales, las

universidades se enfrentan a dificultades que incluyen la carencia de recursos en espacio y

costos a la hora de adquirir maquinas para desarrollar nanociencia, biología, astronomía,

demás lineas del conocimiento humano.

La intención de este proyecto es de proponer un prototipo de laboratorio virtual tipo web 3.0

de acceso remoto virtual a la red de telescopio virtual GLORIA, con el fin de experimentar el

protocolo de conexión y responder al interrogante ligado a este propósito como lo siguiente:

¿Las aulas virtuales optimizarían la realización de las prácticas en el área de astronomía en

la universidad Francisco José de Caldas teniendo como soporte la interconexión de la web

3.0 con el acceso a la red de telescopios del proyecto GLORIA?

11

2.2. Justificación

La justificación de realizar este trabajo nos viene impuesta en primer lugar por la búsqueda

de implementar nuevas formas de aprendizaje por medio de sistemas basados en Laborato-

rios Virtuales en la Web 3.0; persiguiendo que la enseñanza este centrada en el estudiante

teniendo un papel más activo en la construcción de su propio conocimiento, con tecnologías

como la realidad virtual, es posible no solo manipular los experimentos bajo condiciones

que no pueden darse en un laboratorio, sino que también, es posible la interacción percep-

ción e inmersión, en un ambiente tridimensional generado por la computadora donde se

permite realizar simulaciones de experimentos eliminando en gran medida , las dificulta-

des inherentes al montaje, dando la mayor libertad en cuanto la manipulación de ciertos

aspectos mecánicos, técnicos, y económicos que deben considerarse en la implementación

de los experimentos, los experimentos realizados en la computadora nos da la posibilidad

de ejecutarlos repetidas veces bajo condiciones que posiblemente no podrían darse en un

laboratorio real, de esta manera el desarrollo del prototipo del laboratorio virtual ayudara en

el crecimiento del aprendizaje en los estudiantes de las Universidades y en el campo de la

investigación.

2.3. Alcance y Limitaciones

2.3.1. Alcance

El alcance de la realización del prototipo queda restringido a una versión funcional que

permita a un estudiante trabajar en el siguiente escenario:

1. Loguearse y Dirigirse desde la interfaz Web al laboratorio Virtual de Open Sim.

2. Solicitar el uso del laboratorio, esperando a que se encuentre disponible.

3. Visualizar experimento de observación a través de los telescopios.

12

2.3.2. Limitación

La creación de cualquier aplicación de Realidad Virtual o Laboratorio Virtual se inicia

con la definición de los objetivos, de esta manera se debe tener en cuenta la necesidad de

contar con alguien versado en el tema, que tenga el conocimiento y la experiencia apropiada

sobre el entorno al que se va a trabajar y posteriormente, hay que realizar un estudio de

factibilidad en el que se analice si con los recursos humanos y materiales con los que se

cuenta es posible terminar el prototipo, suele ser necesario tener que modificar los objetivos

si las limitaciones existentes impidieran la obtención satisfactoria de los mismos.

2.4. Objetivos

2.4.1. Objetivo General

Proponer e implementar un prototipo de laboratorio virtual basado en la aplicación Web

3.0, que permita experimentar un protocolo de acceso a la red de telescopios del proyecto

GLORIA.

2.4.2. Objetivos Específicos

Para poder cumplir con el objetivo principal es necesario que se lleven a cabo una serie de

tareas que se plantean como objetivos específicos. La realización del presente prototipo

contiene los siguientes objetivos específicos:

Crear e implementar un caso de estudio basado en una sala de laboratorio físico

con sus respectivas características en el laboratorio virtual donde se describa el

funcionamiento del telescopio de acceso web para uso de “web service” tipo educativo.

Formular un prototipo real de acceso remoto usando la experiencia de la red “GLO-

RIA” que permita sentar las bases para la construcción futura de escenarios similares

13

en la universidad Francisco José de Caldas.

Experimentar un protocolo de acceso que permita la comunicación en el prototipo del

laboratorio virtual web 3.0 basado en Opensim y la red de telescopios GLORIA.

14

Capítulo 3

Estado del Arte

El origen de los mundos virtuales fue muy diverso, algunos aparecieron como una extensión

de los chats, para mostrar una imagen de cada uno de los participantes y hacer el espacio

más interactivo. Otros fueron extensiones de juegos que lanzaron una versión para jugar en

línea. En general se suele considerar a los siguientes como los pioneros.

Habitat Se considera el primer mundo virtual como tal. Se trataba de un juego de rol online

lanzado en 1986 que desarrolló Lucasfilm para el ordenador estrella de la época, el Commo-

dore 64. El mundo no era en tres dimensiones pero si contaba ya con representaciones de sus

usuarios, avatares. [15] El mundo estaba "gobernado"por sus usuarios y eran ellos los que

decidían en última instancia. Los avatares podían ser robados e incluso ser asesinados, lo

cual llevó a la creación de cierto desorden y a la creación de avatares con mayores poderes

que intentaban mantener el orden. El software fue vendido y revendido entre compañías

hasta que finalmente fue comprado por Compuserve, que lanzó el juego con el nombre de

Worldsaway. [17]

CitySpace Fue creado en 1993 y fue uno de los primeros mundos virtuales creados por el

usuario, es decir, en él se permitía diseñar objetos e incluso avatares y edificios. [17]

The Palace, [15] Era un servicio de chat que comenzó a ofrecer la posibilidad de diseñarse

un personaje que le representara en las salas de conversación. También se podía modifi-

car la apariencia, la ropa e incluso poner complementos y algunos objetos. Fue lanzado

15

originalmente en 1996 y aunque no es conceptualmente un mundo virtual avanzó algu-

nas de las posibilidades que estarían disponibles en los mundos virtuales que se crearon

posteriormente.

Con lo anterior se han realizado muchos estudios que se dedican a la construcción de

laboratorios virtuales, si bien los primeros intentos de controlar procesos en forma remota

vienen de hace más de veinte años, [4] es en la última década que su desarrollo y aplica-

ción tanto para fines académicos como comerciales acontece en una actividad importante.

Estos esfuerzos de creación han nacido en las universidades donde se han concentrado los

esfuerzos; como: La Universidad de Texas que dispuso desde 1996 de un Laboratorio

de Control Automático para la realización de experimentos en forma local y remota [3].

También en la Universidad de Singapur existe un laboratorio para el estudio experimental

remoto del modelado y control de un servo motor de cc, a través de una página web [3].

[8], en el Laboratorio de Ingeniería de Control de la Universidad del Estado de Oregon,

EE.UU., desarrollo una aplicación de aprendizaje a distancia que permite al usuario conducir

remotamente experimentos. [34], También de la Universidad de Singapur implementan

experimentos de control remoto para sistemas de tanques acoplados usando las estructuras

de control clásicas.

En el Instituto Federal de Tecnología de Suiza se ha diseñado una solución cliente-

servidor multiplataforma basada en PC, destinada a estudiar sistemas dinámicos a través

de Internet [29]. Se conocen también aplicaciones en Robótica [38], Ingenieria Electrónica

[2]; [31] e Ingeniería Química, [37]. Se Realizó un evento internacional auspiciado por

la Asociación Internacional de Control Automático (IFAC, 2001) sobre la enseñanza

del control usando Internet, en ese foro se trataron aspectos como laboratorios remotos y

virtuales, teleoperación, realidad virtual en la enseñanza del control y otros.

En cuanto al sector industrial, National Instruments [36] ha sido líder en el desarrollo de

aplicaciones comerciales basadas en su LabView, tal que la opción de monitorear y controlar

procesos a través de Internet ha pasado de ser una innovación de carácter experimental a

una aplicación industrial, [39] siendo la industria de alimentos y bebidas la pionera en la

utilización de este enfoque de control de vanguardia [35].

16

La evolución de la tecnología web hace posible la interacción entre las personas compar-

tiendo el conocimiento y los mencionados proyectos, nos abre paso para llevar acabo la

adecuada investigación para realizar el prototipo remoto virtual experimentando un pro-

tocolo de acceso a la red de telescopios Gloria, siendo de uso web que permita obtener

resultados y recopilar información que sin duda será de mucha utilidad para ser usada en las

investigaciones científicas.

17

Capítulo 4

Marco Referencial

4.1. Laboratorios Virtuales

Un laboratorio virtual permite el adelanto y perfeccionamiento en áreas tales como lo

son educación, ciencia y cultura, es así como se llega a una definición de laboratorio vir-

tual como la creación de un ambiente electrónico hecho con programas informáticos o

computacionales los cuales introducen aspectos tecnológicos, pedagógicos y humanos para

experimentar, investigar, aprender y elaborar con ayuda de la tecnología algún tema en

específico, cuyo fin también es realizar actividades de tipo prácticas adaptadas de acuerdo

a su uso en un espacio virtual; permitiendo que de una manera clara se transmita la infor-

mación deseada ,sin embargo, existen laboratorios reales o también llamados laboratorios

tradicionales que aunque sean creados los virtuales con total semejanza no van a suplir los

reales.[7] Los laboratorios virtuales inicialmente fueron concebidos como complemento

de los laboratorios reales en el área de ingeniería en el sentido de ofrecer instrumentos

adicionales al aprendizaje tradicional usando técnicas de simulación [41]. Donde se hacía la

entrega de material complementario a través de herramientas de almacenamiento masivo

como CD’s y podría estar acompañado de un libro guía para su manipulación. En algunos

casos concretos, los libros usados como guía de aprendizaje de alguna temática de inge-

niería eran lanzados al mercado con un CD que permite la simulación de algunos de los

18

temas tratados. Actualmente, el uso de los laboratorios virtuales se pone en funcionamiento

mediante la mediante el uso de programas de Software de simulación y animación de

la realidad. Estos programas de propósito específico pueden ser desarrollados para una

asignatura concreta [42]. Los laboratorios permiten diseñar y manipular de forma virtual

una gran cantidad de procesos y operaciones, técnicas y con el tiempo han demostrado ser

de mucho valor para reforzar los conocimientos teóricos adquiridos en las aulas físicas o

ambientes virtuales de aprendizaje. Las plataformas programadas en ambiente Web poseen

un carácter integrador, que permite incluir interfaces interactivas y de fácil navegación para

el usuario. Dan la posibilidad también de combinar elementos y archivos de otros formatos,

tales como imágenes, sonidos, textos y videos, entre otros, y de acceder a aplicaciones de

otros programas. Estas estructuras brindan una gran funcionalidad y flexibilidad para el

diseño de laboratorios virtuales. Con esta idea se diseñó una plataforma estructurada por una

serie de niveles que tienen una organización lógica y jerárquica, los cuales están referidos,

cada uno, a un propósito específico durante la navegación e interacción del usuario con la

misma [43]. Morozas [44] muestra una arquitectura para un Laboratorio Virtual que permite

planear experimentos relacionados con la ingeniería eléctrica y está conformado por compo-

nentes de software y hardware, permitiendo a los usuarios interactuar con objetos, equipos

de medición (osciloscopio, generador de funciones y convertidores analógicos-digital) y

dispositivos electrónicos (transductores) reales. A continuación se muestras los diferentes

tipos de laboratorios virtuales:

4.2. Tipos Generales de Laboratorios Virtuales

4.2.1. Laboratorio Virtuales Software

Son laboratorios virtuales desarrollados como un programa de software independiente,

destinado a ejecutarse en la máquina del usuario y cuyo servicio no requiere de un servidor

Web, es el tipo de programas con instalación propia, que pueden estar destinados a sistemas

operativos Unix, Linux, Windows e incluso necesitar que otros componentes de software

19

estén instalados previamente, pero que no necesitan los recursos de un servidor determinado

(como bases de datos o módulos de software de servidor) para funcionar. [9]

4.2.2. Laboratorios Virtuales Web:

En contraste con lo anterior, este tipo de laboratorios se basa en un software que depende de

la exigencia de determinado hardware que requiere ejecutarse en un servidor, esos recursos

pueden ser: Bases de Datos y software, estos no son programas que un usuario pueda

descargar en su equipo para ejecutar de forma local e independiente. [9]

4.2.3. Realidad Virtual

El concepto de realidad virtual se define como la capacidad de reproducir una situación

real, mediante medios mecánicos o electrónicos para dar una percepción inmersiva a la

realidad.[11]

4.2.4. Laboratorios Remotos

Permiten operar remotamente cierto equipamiento, bien sea didáctico como maquetas

específicas, o industrial, además de poder ofrecer capacidades de laboratorio virtual. En

general, estos laboratorios requieren de equipos servidores específicos que les den acceso a

las máquinas a operar de forma remota, y no pueden ofrecer su funcionalidad ejecutándose

de forma local. Otro motivo que hace dependientes estos laboratorios de sus servidores es la

habitual gestión de usuarios en el servidor.[11]

4.2.5. Laboratorios Electrónicos

Una de las soluciones más interesantes en la educación universitaria son los laboratorios

electrónicos, o e-laboratorios. Estos tiene el mismo objetivo que los laboratorios tradiciona-

les: Dar a los estudiantes la oportunidad de poner en práctica las habilidades y conocimientos

20

recientemente adquiridos realizando diferentes prácticas y experimentos a través de un uso

ilimitado y repetido.[11] El estudiante puede acceder a los equipos del laboratorio a través

de un navegador y conectarse a entornos de entrenamiento simulados o reales, pudiendo

ejercitar habilidades diversas sin riesgo alguno. Así los estudiantes pueden aprender median-

te prueba y error: sin miedo a sufrir o provocar un accidente; sin avergonzarse si requieren

realizar varias veces la misma práctica, ya que la pueden repetir sin límite; sin temor a dañar

alguna herramienta o equipo. Además, también pueden asistir al laboratorio cuando ellos lo

quieran, y hasta escoger aquellas áreas del laboratorio que resultan más significativas para

realizar prácticas sobre su trabajo. Tambien es posible llevar a cabo experimentos de forma

estructurada o incluso más abierta, en la que los estudiantes desarrollan habilidades de

resolución de problemas, observación interpretación y análisis de los resultados, de forma

similar a la que los investigadores realizan.[11]

4.3. Second Life

Second Life (SL) es un mundo virtual que consiste en un terreno dividido en Regiones

de tamaño fijo, donde los usuarios controlan avatares e interactúan entre ellos. Además

pueden crear, modificar o eliminar objetos según los permisos que tengan los avatares en

cada región.[26]

4.4. Opensim

Es una plataforma para dirigir a un entorno virtual, soporta regiones independientes múl-

tiples, puede ser utilizado para crear un entorno virtual que puede ser accedido por una

variedad de clientes de múltiples protocolos. El desarrollo de OpenSim está muy relacio-

nado con la plataforma SecondLife que pertenece a Linden Labs y está formado por dos

componentes principales [25]:

El cliente es una aplicación software constituida por una ventana o interfaz de usuario

el cual navega a través de un espacio tridimensional, además esta interfaz le da la

21

posibilidad al usuario de realizar búsquedas, vista de mapas, gestión de inventario,

comunicación por chat, interfaz de configuración y personalización del usuario y la

administración de clientes.

El servidor es la aplicación software que se comunica con el cliente aceptando

peticiones y emitiendo respuestas; la aplicación servidor está conectada a una o más

bases de datos donde se almacenan todos los activos de los usuarios y los diferentes

artículos del inventario.

En enero del 2007, Linden Labs liberó el código de la aplicación cliente, dejando el código

a disposición de un gran número de usuarios y desarrolladores con la finalidad de desarrollar

un nuevo servidor de aplicaciones y datos de código abierto, constituyéndose así un grupo

de trabajo y de investigación a través del proyecto denominado Open Simulador.

Para utilizar OpenSim hay que elegir una aplicación cliente y luego elegir el servidor de

acceso. El cliente por defecto es de código abierto proporcionado por Linden Labs; OpenSim

puede ser utilizado por diferentes tipos de usuario para diferentes cosas. [25]

4.4.1. OpemSim para la Educación

Como señalan Daniel Livingstone y Jeremy Kemp [24], la interfaz tridimensional resulta

mucho más alegre para estudiantes que encuentran aburridas las plataformas de aprendi-

zaje virtual (tales como WebCT y Moodle) porque sólo ofrecen entornos bidimensionales.

Muchos estudiantes ya se manejan con soltura en entornos inmersivos tridimensionales,

propios de los juegos de consolas y video juegos online. Según estos autores, «la expe-

riencia afectiva que los estudiantes disfrutan en estos entornos, no se puede comparar a

las plataformas actuales de aprendizaje virtual. En este sentido viene a subrayar Giulio

Prisco [27], 3D es un interfaz mucho mejor. Esto no nos debe sorprender: mientras que

hemos estado trabajando con los documentos durante sólo unos cientos de años, hemos

desarrollado respuestas rápidas al universo verdadero 3D, como escapar de depredadores y

cazar presas, durante centenares de miles de años. Ahora que la tecnología lo permite, la

22

realidad virtual 3D se está convirtiendo en el interfaz preferido por los usuarios. También

merece atención la diversidad de estilos de aprendizaje, que es una cuestión ignorada en la

enseñanza tradicional, la cual se apoya principalmente en la palabra escrita. En entornos

tridimensionales virtuales como OpemSim, el aspecto visual y kinestésico está presente de

modo permanente. Además de las diferencias individuales en los modos de aprendizaje de

los alumnos, ciertas disciplinas, como, entre otras, las artísticas (pintura, escultura, diseño,

fotografía) están, básicamente, orientadas hacia modos de aprendizaje y enseñanza poco

verbales. Philip Rosedale [27], directivo de Linden Lab, señala la oportunidad de los entor-

nos de realidad virtual para la memoria: Si intentaran recordar los tres últimos archivos a

los que se accedio en la carpeta Mis Documentos, probablemente no los recordarían, pero

es más probable que puedan recordar una lista de objetos de de algun lugar. Esto se debe a

que han construido un espacio tridimensional en la cabeza en el que almacenan cosas. Del

mismo modo, la gente construye espacios en OpemSim creando contextos únicos que son

fáciles de recordar. ¿Por qué puede ser útil para la educación trabajar con un soporte como

OpemSim? En palabras de Linden Lab, OpemSim ofrece un entorno único y flexible para

los educadores interesados en la enseñanza a distancia, el trabajo cooperativo por medio del

ordenador, la simulación, los estudios de new media y la formación empresarial.

4.5. E-Science

E- science es un concepto que refiere a todas las actividades científicas, que dependen

del uso intenso de cómputo. E- science se hace en diversas áreas científicas, entre ellas la

Astronomía y Astrofísica, la Física, Bio-Informática, Medicina, Ingeniería Climatología y

Ciencias de la Tierra, etc.[18]

4.6. Web 3.0

En los últimos años se ha ampliado el desarrollo de aplicaciones en el territorio de la web

2.0, término empleado por Timo Reilly en el 2004, fundador de O’Reilly Media, para

23

denominar una segunda generación de servicios basados en la web, pero apoyado en los

recursos humanos y tecnológicos, enfocando la idea de compartir información de forma

más dinámica y menos estática, mejorando el diseño de las paginas, usando el criterio de

interoperabilidad, aumentando servicios web, fortaleciendo el uso de los servicios de redes

sociales, alojamiento de audios y videos (streaming), ampliando el uso de las blogs, wikis,

foros, y plataformas educativas y empresariales apoyándose en el concepto de colaboración

online, es decir, generando más y más interactividad entre usuarios.De acuerdo al compendio

realizado por la Unión Europea en “E-learning para Innovar” se estableció los siguientes

principios básicos para e-learning y que hacen uso de la web 2.0 con proyecciones a la 3.0.

Principios básicos de la Web 3.0 :

Los propios usuarios están en la capacidad de administrar los datos en la web y

ejercer control sobre ellos. Se puede manipular, compartir y modificar fácilmente y

libremente.

La web se convierte en una plataforma de entrega (permitiendo a los usuarios gestio-

nar) de aplicaciones y servicios enteramente a través de un navegador.

Los efectos de red son creados por una arquitectura de participación que anima a

los usuarios para agregar valor a la aplicación, ya que lo utilizan. Esto está en agudo

contrastecon jerárquicas de control de acceso en aplicaciones en las que los sistemas

de categorizan a los usuarios en roles con diferentes niveles de funcionalidad.

La innovación en el montaje de sistemas y sitios compuestos por la unión decaracte-

rísticas de desarrolladores independientes (un tipo de desarrollo çódigo abierto’).

Aparición de modelos de negocio ligeros habilitados por el contenido y la distribución

de servicios.

Interfaces funcionales, interesantes, interactivas y de fácil uso.(Plataformas como

Moodle, Sakai u OpenSim).

24

Creación y consolidación de Redes sociales. Todo esto, teniendo en cuenta como

proyección a que los mismos usuarios finales son quienes clasifican y ordenan la

información, tendiendo a establecerse como una democratización de los medios, que

se encuentran al alcance de cualquier usuario.

Lo más importante es que el usuario o cibernauta estándar, pasa de ser un consumidor, a

ser un productor de información y de conocimiento. Con estos cambios del cibernauta, se

proporciona una evolución en poco tiempo y ahora se enfoca la mirada en la web 3.0. Esta, es

la descripción de la evolución en el uso y de la interacción de los usuarios en la red, migrando

a la web de información, a una plataforma de base de datos, apoyándose en los espacios o

mundos 3D y ampliando la interactividad de las redes sociales y comunidades colaborativas

con ayuda de las computadoras. Cabe señalarse que, gracias a las computadoras personales y

los teléfonos móviles, en unión con la telefonía inalámbrica y hardware de última generación,

creando una ampliación de cobertura de la web, siendo este un punto neurálgico para el

nacimiento de la necesidad de los usuarios, para comenzar a llevar su vida cotidiana a un

mundo virtual que supla sus necesidades básicas, donde se proyecten los pensamientos e

ideas, los gustos, costumbres y creencias que los caracterizan, siendo estos los aspectos que

toman fuerza en los mundos virtuales.

4.7. Proyecto GLORIA

GLORIA significa “GLObal Robotic-telescopes Intelligent Array”. GLORIA será la primera

red de telescopios robóticos del mundo de acceso libre. Será un entorno Web 2.0 donde los

usuarios pueden hacer la investigación en la astronomía mediante la observación con teles-

copios robóticos, y/o análisis de los datos que otros usuarios han adquirido con GLORIA, o

desde otras bases de datos de libre acceso, como el Observatorio Virtual Europeo (http://

www.euro-vo.org).[25]

25

4.7.1. ¿Quién puede acceder a GLORIA?

La comunidad es la parte más importante del proyecto GLORIA. El acceso será libre para

todo aquel que tenga una conexión a Internet y un navegador web. Por lo tanto, estará abierta

no sólo a los astrónomos profesionales, sino también a cualquier persona con un interés por

la astronomía.[25]

4.7.2. ¿Qué servicios ofrecerá GLORIA?

Muchas comunidades de Internet ya se han formado para acelerar la investigación científica,

a colaborar en la documentación de algo, o como proyectos sociales. La investigación en

astronomía sólo puede beneficiarse de atraer muchas miradas hacia el cielo – para detectar

objetos en el cielo requiere mirar en el lugar correcto en el momento oportuno. Nuestros

telescopios robóticos puede buscar en el cielo, pero las grandes cantidades de datos que

producen son mucho mayores que los astrónomos tienen tiempo para analizar. GLORIA

proporcionará una forma de poner miles de ojos y mentes en el problema. GLORIA está

destinada a ser una estructura Web 2.0, con la posibilidad de hacer experimentos reales.

La comunidad no sólo va a generar contenido, como en la mayoría de la Web 2.0, sino

que también podran controlar telescopios de todo el mundo, tanto directamente como a

través de las observaciones programadas. La comunidad va a tomar decisiones para la red y

que le dará a la “”inteligencia”” a Gloria, mientras que el trabajo esclavo (por ejemplo, la

elaboración de los horarios del telescopio que satisfacen diversas limitaciones) se llevará a

cabo por los algoritmos que se desarrollarán para este fin.[26]

4.7.3. ¿Cómo GLORIA afrontará a los desafíos?

EL proyecto GLORIA definirá estándares, protocolos y metodología para:

El control de telescopios robóticos y todo relacionado con la instrumentación, es

decir, cámaras, el filtro de ruedas, cúpulas, etc

26

Dar acceso a la Web de la Red: el acceso a un número arbitrario de telescopios

robóticos a través de un portal web.

La realización de experimentos on-line: Será capaz de diseñar entornos web espe-

cíficas para el control de telescopios para la investigación científica en algún tema

específico.

Llevar a cabo experimentos fuera de línea: Será capaz de diseñar entornos web

específicas para el análisis de Astronomía de meta-datos producido por Gloria o otras

bases de datos.”‘[25]

Figura 4.1: 18 Telescopios de la red Gloria Año 2014

27

4.8. Sistema Gloria

Figura 4.2: Sistema Gloria [46]

El Sistema de GLORIA, asume el papel correspondiente del controlador a través de la red

de Telescopios Robóticos. La comunicación entre estas dos partes se realiza a través de

Internet, utilizando un protocolo de alto nivel se define en las normas Gloria (Interfaces de

telescopios robóticos)[28]. El Sistema de GLORIA a su vez se compone de dos elementos

con fines muy diferentes. La primera corresponde a la capa de presentación del sistema,

es decir, el subconjunto de software que es la interfaz entre los usuarios, y el segundo

elemento son los servicios. Estos servicios reúnen toda la lógica del negocio de Gloria y son

identificadas como el núcleo de todo el sistema. Cualquier cosa que un usuario puede querer

hacer, es decir, controlar un telescopio, realizar un experimento o votar por una imagen, se

llevará a cabo a través de una operación de servicio web incluida en algún servicio dentro

de la capa de servicios de GLORIA [27].

28

4.8.1. Arquitectura de Red

La red GLORIA consiste en tres componentes principales: telescopios, los usuarios y

el procesador lógico que los conecta a todos como una red. Siguiendo un enfoque de

controlador de dispositivo, se divide el software en dos áreas distintas, Figura [4.2] La

zona del fondo, llamado Robotic Telescopio de red, que corresponde con el subconjunto de

software que es funcionalmente y topo-lógicamente ubicado en cada telescopio separado.

Este software (Sistema robótico Telescopio o RTS) toma el papel de un dispositivo con el

enfoque propuesto, y ofrece la posibilidad de tele-operación de cualquier telescopio. Esta

red de telescopios crecerá a medida que los usuarios propietarios ponen sus telescopios

disponibles en GLORIA [30].

Figura 4.3: Arquitectura de Red GLORIA [47]

La arquitectura de red GLORIA ha sido diseñado de acuerdo con la metodología orientada

al servicio (SOA) [30]. La razón principal para la aplicación de este paradigma es hacer su

29

funcionalidad del proyectó GLORIA independiente de los diversos caminos o interfaces

utilizadas por la comunidad. De esta forma se logra la independencia de cualquier tecnología

en particular que no sea el transporte de la banda. Por lo tanto, la única cosa que requiere

cualquier aplicación cliente, que es parte de la capa de presentación, es utilizar la API

GLORIA consumiendo cualquiera de sus servicios (ver Fig. 4.4).

Figura 4.4: Interfaz Gloria de aplicaciones programadas [47]

4.8.2. Programador Red de Telescopio

Con el fin de gestionar todas las peticiones de observación por los usuarios, es necesario

desarrollar un planificador que es apto para todos los telescopios robóticos en la red

[32], teniendo en cuenta que cada telescopio tiene su propia política de planificación y

la observación. Este planificador central organiza observaciones teniendo en cuenta las

propiedades del telescopio distintas, la naturaleza del objetivo que deberá observar y algunas

restricciones establecidas por los astrónomos. La solución del planificador se basa en las

siguientes partes:

Plan a Observar : Se trata de un paquete, en forma de un archivo XML, que contiene

todo lo que el planificador (y eventualmente un telescopio) necesita saber para llevar

a cabo la observación. La observación de un Plan incluye restricciones (ventana de

tiempo específica, telescopio específico, filtros específicos, la altura sobre el horizonte,

la separación de la luna, tiempo después del crepúsculo / antes del amanecer, etc.)

y una secuencia de instrucciones en un lenguaje de programación básico de cinco

30

verbos: Target (Que(objeto de coordenadas) el telescopio debe señalar el momento),

Camera (ajustes de configuración, tales como ventanas, agrupación , etc.), Expose

(definición de tiempo, repeticiones o la duración y filtros), Label (marca el comienzo

de un bloque lógico en el programa, pero no tiene ningún efecto físico y Repeat (se

utiliza después de un bloque de instrucciones que indiquen las repeticiones de todo el

bloque).

Un programador local: Cada telescopio tiene un planificador propio (posiblemente

con mucho más de GLORIA en su mente - es decir, un telescopio GLORIA puede

estar ofreciendo sólo una parte de su tiempo, y esto puede ser intercalando las tareas

de GLORIA privadamente y no necesariamente con un intervalo de tiempo dedicado).

Un planificador central: Esto proporciona el calendario global de la red robótica.

En este modelo, teniendo en cuenta un trabajo como una petición de ejecución de un Plan de

Observación, el planificador central anuncia esto a los programadores locales de telescopios

que pueden hacer el trabajo, y cada programador local va a responder, ya sea con una

propuesta (por cómo y cuándo puede hacerlo), o una negativa. El planificador central de

la mejor propuesta acepta (determinada por la política), y espera la confirmación de que

el trabajo se ha completado, o una disculpa que el trabajo no era o no se llevará a cabo

de acuerdo con la propuesta original. El planificador central gestiona todos los puestos

de trabajo en el sistema de GLORIA, la recepción de nuevos puestos de trabajo de la

herramienta de edición, la publicidad de ellos (y volver a la publicidad como sea necesario),

aceptando la mejor propuesta (teniendo en cuenta una política global) y retirarse tareas

cuando están hechos. La política programador se basa en el Karma, pero se requiere una

capa adicional para dar prioridad a algunos de Observación. Esta capa permite que el sistema

pueda ejecutar alertas es decir PSG u observaciones de supernovas [32].

31

4.9. Gestión de los Telescopios

Gloria es una red heterogénea, pero todos los telescopios deben presentar una interfaz común

con el fin de integrarse en el sistema. Esta interfaz es la capa externa de la arquitectura

modular y escalable que todos los sistemas de telescopio robótico (RTS) deben cumplir para

ser incluido en la red. A continuación se describe esta arquitectura y todos los pasos que un

RT tiene que tomar para completar el proceso de registro.

Figura 4.5: Arquitectura RTS (a) Telescopio Robótico en la red GLORIA (b) [48]

4.9.1. Arquitectura RTS

En la figura 4.5 muestra todos los componentes del sistema de telescopio robótico y las

comunicaciones entre ellos.

El Dispositivo de Telescopio Robótico (RTD) controla y supervisa cada dispositivo físico en

el Telescopio Robótico (RT), y pertenece a una de un número de diferentes clases, teniendo

en cuenta los diferentes dispositivos que un telescopio tiene comúnmente, es decir, cúpula,

montaje, etc. cada tipo de RTD es compatible con las propiedades estándar del dispositivo

correspondiente, y una interfaz distinta se define para cada tipo de RTD. Estas interfaces se

32

utilizan a su vez por el Controlador de Telescopio Robótico (RTC). Además de los RTDs

para el control de hardware, también hay un RTD que específica para la gestión de la Base de

Datos de Telescopio Robótico (RTDB) que contiene las imágenes del sistema que adquiere.

El RTC gestiona los dispositivos (RTD / RTDB) y la comunicación entre la interfaz del

Telescopio Robótico (RTI) y los RTD. También es responsable del estado de dispositivo

de control y de seguridad. Usando la información de estado de IDT, el RTC se encarga

de realizar todas las acciones necesarias para mantener el telescopio en un estado estable

y en buen estado. Por último, el telescopio robótico de interfaz (RTI) es la interfaz de

comunicación entre los Servicios Gloria (GS) y RTS. Todas las interfaces dentro de la

estrategia en tiempo real (RTI y RTD) son independientes de la tecnología (Java, C ++, etc.).

Al igual que otros sistemas de telescopios [34], estas interfaces se han definido mediante

WSDL (Web Services Description Language). Por lo tanto, el propietario de un telescopio

puede desarrollar toda la RTI utilizando cualquier tecnología que soporta interfaces de

servicios web.

4.9.2. Registro RT

Con el fin de hacer más fácil la integración de nuevos telescopios en la red Gloria, todo

el software RTS estará disponible para los propietarios, así como instrucciones detalladas.

Las únicas modificaciones que los propietarios tienen que hacer son las relacionadas con la

parte dependiente de Hardware de los RTD. Una vez que el dueño del telescopio tiene el

sistema instalado en su telescopio y que ya se registra en la red de Gloria, el RT tiene que

someterse a varias etapas o fases antes de ser plenamente integrada en la red GLORIA:

Prueba: En este paso, el propietario RT ya ha cumplido la solicitud de integración de

la red GLORIA, en el que todos los datos del telescopio, los dispositivos y operaciones

implementadas son detallados. Cuando el RT entra en esta fase se convierte en la

versión pre-alfa, y el sistema ejecuta algunas pruebas para verificar los aspectos

críticos de la comunicación con el RT y sus características básicas. Una vez que se

han superado las pruebas automáticas, el telescopio está listo para ser validado a partir

33

del Sistema Gloria.

Validación administrativa: El propietario y un subconjunto de usuarios selecciona-

dos por él / ella tienen acceso exclusivo para verificar el funcionamiento de la RT.

En este paso, el BE- RT viene versión Alfa. Comparan las operaciones disponibles

ofrecidos por el propietario para los que realmente implementadas y sus resultados.

El objetivo de esta fase es refinar la funcionalidad de la RT a nivel de calidad deseado

del propietario, antes de abrir a la comunidad.

Validación Colectiva: El uso del telescopio está abierto a la comunidad, pero no

habrá ningún impacto directo en su karma. Cada usuario puede operar el RT y reportar

incidencias sobre los problemas que han encontrado en ella. El RT alcanza el estado

Beta. El objetivo de esta fase es obtener, a través de toda la información obtenida

de las experiencias individuales, un informe de validación global que ayuda a los

administradores de Gloria para decidir la integración final de la RT.

Completo: El RT está completamente listo para ser utilizado por la comunidad con

activar su karma. Aquí, el telescopio alcanza el estado de salida. Un valor inicial del

karma se asigna en base a los resultados dados por el último informe de validación

global generado durante la fase Beta.

4.9.3. Administración de Usuarios y el Sitio Web

Los usuarios finales de la red son tanto los propietarios de las RTs y cualquier persona que

quiera ejecutar experimentos astronómicos. Tienen un punto de acceso al sistema basado en

la Web común.

4.9.4. Autenticación del usuario

La autenticación y gestión de usuarios es una de las cosas más importantes para la crea-

ción de una red social. En el caso de GLORIA, que ha implicado varias universidades y

centros de investigación, y en las futuras escuelas, asociaciones y otros, esto se hace más

34

importante porque es necesario dar acceso a la red para un gran número de usuarios [35].

Para hacer este trabajo más fácil, se ha realizado un estudio sobre las diferentes tecnologías

para la autenticación (gestión de usuarios y autenticación en diferentes aplicaciones web),

concluyendo que el uso de un servicio de autenticación federada ayuda para la pose este

fin. Autenticación federada permite a cualquier organización para implementar su propio

sistema de autenticación, y conectarlo a diferentes aplicaciones web. Las ventajas de este

tipo de funciones de autenticación son muchas: fácil de implementar, enfoque escalable, in-

tegración rejilla de un gran volumen de usuarios, utilizar el mismo sistema de autenticación

en diferentes aplicaciones web que utilizan diferentes tecnologías, etc. [36]. Hay muchos

ejemplos en los que la autenticación federada ha tenido éxito. A nivel europeo, el proyecto

de la cigüeña [38] permite a los usuarios autenticarse mediante su identificación electrónica

nacional, y hoy en día se trata de utilizar para establecer relaciones con la administración

pública. La iniciativa eduGAIN [37] es un servicio que identifica a los usuarios en todo

el mundo desde la comunidad de investigación y educación. En el caso de este proyecto,

un proveedor de autenticación (SP) permitirá a las organizaciones para autenticar a los

usuarios que han hecho acuerdos con el proyecto GLORIA que serán desplegados, por

ejemplo: Usted es un centro de educación secundaria que tiene un telescopio y quiere

compartirlo en la red GLORIA, y quiere dar acceso a la red para todos los estudiantes. En

este caso el centro instalaría un proveedor de identidad (IdP), y conectarlo con el proveedor

de servicios de GLORIA. En el caso de usuarios que no pertenecen a ninguna organización,

GLORIA tendrá su propio proveedor de identificación que contiene la base de datos de los

usuarios registrados. La figura 4.6 muestra un ejemplo de la arquitectura del sistema de

autenticación que será implementado en el proyecto GLORIA. El usuario se registrará en

cualquier proyecto de aplicación web, se dirigirá al usuario GLORIA Servicio de federación,

y el usuario será capaz de autenticarse usando su proveedor de servicios o centro de la base

de datos de usuario GLORIA. Una vez identificado por el sistema, será capaz de navegar

entre las diferentes aplicaciones web con su papel, y sin tener que volver a identificarse.

35

Figura 4.6: Autenticaión del Usuario [50]

4.9.5. Herramienta de Creación

La página web de GLORIA proporciona una herramienta de autor, que integra los diferentes

componentes de la web, llamadas portlets, para los experimentos en línea y fuera de línea.

Esta herramienta de creación proporciona una interfaz web fácil de usar para la creación de

nuevos experimentos.

La herramienta de creación es principalmente una paleta de componentes Web organizados

por categorías, como puede verse en la Figura. 4.7. (a). Actualmente, existen tres categorías

diferentes, de propósito general en línea y fuera de línea. Los experimentos se crean por

simple adición de componentes web pueden ser de cualquier página usando arrastrar y

soltar.Ademas, cada componente web tiene una configuración que puede ser modificado

por el diseñador del experimento, como puede verse en la Figura. 4.7. (b). Los nuevos

componentes web se pueden escribir y se añaden a la paleta en cualquier categoría, pero el

administrador de la web es responsable de desplegar a través del panel de control Liferay

[39].Un ejemplo de cómo crear y configurar un experimento se puede ver en un video en el

canal de YouTube GLORIA [40].

36

Figura 4.7: Herramienta de Autoría GLoria [51]

4.9.6. Experimento

GLORIA va a llevar la ciencia a los ciudadanos, al permitir la investigación de un tema

astronómico específico a través de un experimento, en el que los usuarios serán guiados

a través de las diferentes tareas de la investigación que se requiere. Estos experimentos

son de dos tipos: En línea (que requieren un telescopio) y fuera de línea, que trabajan

en los datos existentes producidos por la red GLORIA o derivados de otras bases de

datos, tales como el Observatorio Virtual Europeo. Experimentos en línea se basan en la

observación de los planetas, que se define según la sección, y se clasifican en función de

(Fijo, Programado o alerta) y la forma (por lotes o interactiva). Experimentos fijos ejecutan

en un momento elegido por el usuario, programado uno a la vez elegido por el sistema,

y alertas que se ejecutan cuando se activa mediante una señal externa. En cuanto a la

forma en que el experimento se lleva a cabo: El modo interactivo permite la tele operación

del telescopio, con acceso semidirecta (mediada por el software en el telescopio) a los

dispositivos individuales, tales como cámaras o ruedas de filtros, mientras que el modo por

lotes se refiere a la ejecución un plan de observación pre programado. Esto produce seis

37

combinaciones, para todos los cuales existen usos válidos. Los experimentos fuera de línea

permiten a los usuarios usar la información almacenada en la base de datos de GLORIA. Hay

varios tipos de experimentos fuera de línea: El experimento .Encuentra tu estrella"permite

a un usuario para obtener la descripción de objeto y una imagen para impresión de alta

calidad; el objetivo del experimento .actividad de control solar.es el estudio de la actividad

solar (manchas solares), la aplicación de una metodología para el cálculo de los parámetros

astrofísicos; el usuario puede verificar si un brillo de las estrellas la disminución se debe

a la ocultación de la estrella por un objeto del Sistema Solar (por ejemplo, asteroides),

solicitando una .ocultación estelar.experimento; el usuario puede buscar transitorios ópticas

en una parte adecuada del cielo que solicitan un experimento "transitorios óptica"; la

"Predicción de la ocultación de estrellas.experimento puede predecir posible ocultación de

estrellas gracias a unas efemérides solares objeto del sistema; La "Búsqueda de la evolución

de las estrellas variables con el tiempo.experimento permite al usuario decidir si una estrella

muestra cambios significativos en el período de variabilidad y / o la forma de las escalas

de tiempo del orden de años; el usuario puede clasificar un objeto de asistir a su curva de

luz; en este caso, la solicita fuera de línea experimento se llama Çlasificación de objetos

variables"[29] Figura 4.8.

Figura 4.8: Las instantáneas de las dos interfaces web de GLORIA. Izquierda: El Sol como

se observa por el telescopio solar de 25 cm en el Observatorio del Teide. Derecha: La

nebulosa M 17 según lo observado por el telescopio TELMA de 60 cm en la estación

BOOTES-2 en Algarrobo Costa.[28]

38

4.9.7. Karma

Karma es un índice que mide la reputación de un usuario en GLORIA. Los usuarios

participan en GLORIA votando por imágenes, incluyendo comentarios, etc...., es decir, la

contribución de la ciencia cada vez mayor. Se utiliza en numerosas redes sociales como

Digg, eBay, etc. Este índice se calcula automáticamente a intervalos por el Sistema de

GLORIA como una función de la participación de cada usuario y la aplicación de políticas

específicas que se pueden establecer de forma dinámica. El componente de Karma en

GLORIA se basa en la actividad social [41] módulo de Liferay. Este módulo permite a las

normas de valoración que se definirán en función de las acciones del usuario sobre el sitio

Web. Cada pieza de información que se presenta (llamado un recurso) puede ser evaluada

por los usuarios a través de la ejecución de acciones sobre sobre ellos. Por ejemplo, un

usuario puede votar una imagen, escribir un comentario, etc. Normas de valoración utilizan

dos mediciones: Puntos de participación son ed Award-al usuario que realiza la acción, y

Puntos de cotización se otorgan al creador del recurso, con un usuario de puntuación total

es la suma de estos.

Figura 4.9: Interacción entre Karma y el modelo económico [52]

El módulo de Karma transforma estos puntos en un valor de karma en el rango 0-10. Una

vez que se evalúan los usuarios, GLORIA puede asignar el tiempo de observación, sino

39

que se establece un conjunto de reglas para asignar este tiempo de acuerdo con el karma es

una tarea compleja y exigente de recursos. Se necesita otro punto de vista y el mundo real

nos puede dar una respuesta. ¿Qué utilizamos en el mundo real a los recursos de comercio?

El dinero, por lo que se propone introducir una moneda virtual, llamado GLORIUS, a

pagar por el tiempo de observación. La cantidad de GLORIUS un usuario gana dependerá

de su participación en la red, es decir, su karma. A continuación, puede pasar GLORIUS

cada vez que hacen una reserva, por lo tanto ventilación pre usuarios individuales de tomar

todo el tiempo de observación disponible para ellos mismos. Esto implica una definición

de un modelo económico. Este enfoque se está utilizando para la gestión de recursos y la

programación en otros campos como la computación Grid [42]. Este sistema de reservas y

asignación de tiempo se llevará a cabo a través del uso de las subastas. De esta manera, los

usuarios podrán competir por el tiempo de observación. Las subastas se utilizan en muchas

plataformas, como eBay, para ajustar automáticamente los precios en base a las valoraciones

realizadas por una comunidad de usuarios. El precio de una ranura de tiempo de tiempo

de observación en una RT específico se fijará mediante este método. Todo este proceso se

muestra en la Figura. 4.9.

4.9.8. Resultados Gloria

Durante los tres años del proyecto, el consorcio GLORIA integrará 17 telescopios, con 12 de

ellos ya en servicio y de trabajo en diversos campos científicos y de divulgación al público,

tres más de empezar a operar con Gloria, y dos más que se instalarán durante la vida del

proyecto. Una vez que todo el software de estrategia en tiempo real ha sido desarrollado y

probado, un plan de despliegue progresivo se definirá con el fin de integrarlo en cada RT.

Al final, todos los RTs serán gestionados por la red GLORIA utilizando la misma interfaz.

Por otra parte, un conjunto de los experimentos se explica en el ítem Programador de red

de telescopio se realiza para evaluar el funcionamiento del sistema en su conjunto. En la

misma manera que despliegue RT (y anterior), se lanzó también progresivamente el lado del

40

sistema GLORIA, con el paso por las pruebas de paso y el despliegue de todos los módulos

del sistema.

Figura 4.10: Experimento Interface Solar TAD

Hasta ahora, sólo un experimento se ha creado a través de la herramienta de creación

que se ha descrito anteriormente. Este es un experimento solar que está compuesto por

los siguientes componentes: Web de la cámara CCD, cámaras de vigilancia, montaje y

domo (ver Figura. 4.10). En la actualidad, cuatro telescopios se han integrado en la red

GLORIA: OM [43], TAD [44], BOOTES-1 y BOOTES-2 [45]. El experimento solar se está

ejecutando en este momento a través de los telescopios OM y TAD, ya que estos son los

únicos telescopios solares de la red.

41

Capítulo 5

Desarrollo, Analisis y Diseño del

Prototipo

Laboratorio Ingeniería Universidad Distrital

Figura 5.1: Laboratorio Practicas Ingenierías

En la universidad distrital hay aulas habilitadas para llevar a cabo experimentos relacionados

con la materia astronomía para poder hacer esta implementación física se deben tener los

siguientes recursos: Telescopio, PCs, actualmente la universidad no cuenta con los recursos

mencionados (Figura 5.1) para realizar dichas prácticas de estudio, por lo tanto uno de los

42

objetivos es el caso de estudio que se llevara a cabo por medio de un diseño de laboratorio

virtual (Figura 5.2) que estará dado de la siguiente manera:

Figura 5.2: Laboratorio Virtual WebUdistrital

Servidor donde se aloja el sitio del laboratorioVirtual: Estara basado en la utilización de

dos protocolos de LSL que ofrece en su api XLM-RPC y HTTP.

XML-RPC permite responder a peticiones iniciadas entre el cliente para poder

interactuar entre opensim y la web semántica

XmlRpcHubUri = http://webudistrital.com

HTTP es utilizado para el transporte de los mensajes o peticiones teniendo en cuenta

los procedimientos ejecutados y los parámetros a la hora de la comunicación.

Autenticación del usuario La autenticación estará basada entre los dos protocolos XLML-

RPC y HTTP, con el método Login realizara la comunicación si el usuario existe, si no

realizara un método de no validación para la seguridad

Lanzamiento de la aplicación Una vez establecidos los protocolos y las interfaces de

comunicación entre los distintos componentes involucrados en el sistema y logueado el

usuario como un usuario avatar

Hay tres tipos de usuario los cuales son:

Estudiante: es el avatar más básico de los tres este permite el acceso al laboratorio virtual,

agendar el sitio si está disponible para las prácticas y hacer uso de los telescopios y otras

herramienta de la sala.

43

Docente: es el encargado de realizar las asignaciones de aula dependiendo de la disponibili-

dad, es el encargado de realizar las tutorías y ayudas en el aula virtual.

Administrador: es el encargado del acceso de los usuarios en la plataforma virtual, adicio-

nalmente es quien realiza la gestión en general de la plataforma. (Figura 5.3)

Figura 5.3: Comunicación de la Arquitectura WebUdistrital

El análisis y el diseño del prototipo se baso en los modelos de Lenguaje de Marcos Concep-

tuales LMC, siendo un lenguaje de modelamiento enfocado en la abstracción y contextuali-

zación del conocimiento llevando acabo los objetivos propuestos, a continuación se muestra

su diseño.

44

5.1. Puntos de Vista Modelos

5.1.1. Punto de Vista de Organización

En el metamodelo Punto de Vista de la Organización intervienen diferentes objetos como la

interfaz, el rol la colaboración el actor, la localización, donde cada uno tiene una función

específica y se relacionan entre si dependiendo de su función. Este lugar está dado en

un espacio virtual como una dirección web, luego se toma la definición del actor, el más

importante porque es el actor cuya función tiene una situación bien específica, también se

puede definir como un concepto estructural que ayuda a representar entidades, personas y

en general cualquier instancia que ayude a generar un comportamiento; el rol tiene como

función representar la funcionalidad que el actor cumple, la interface tiene otro concepto en

donde debe predominar, está en cada una de las capas, es la forma de comunicación que

tiene la capa de negocio con el entorno y colaboración, no se puede confundir con el rol,

que tiene como función la asociación de roles, se usa para representar un comportamiento

que generalmente es coyuntural. El punto de vista de la organización tiene como punto

focal la organización interna de una empresa, departamento o una entidad organizacional,

también es posible que se presenten otros tipos de organizaciones, pero lo más importante

de este es: La vista, es la que ayuda a la identificación de competencias, autoridades y

responsabilidades de una organización.

Figura 5.4: Metamodelo Punto de Vista de la Organización

45

Aquí se identifica cada uno de las responsabilidades que se tienen en la organización:

El actor representa entidades y/o personas, donde se tiene un comportamiento y se asigna

un rol; el rol representa la función que el actor cumple, la interface es una colección de ope-

raciones que representan los servicios de la organización siendo la forma de comunicación

en la capa de negocio con el entorno, y la colaboración tiene como función la asociación

del rol, se usa para representar un comportamiento de un grupo de roles. En el metamodelo

Punto de Vista de la organización se muestra la identificación de competencias, autoridades

y responsabilidades de una entidad u organización (Figura 5.4).

Figura 5.5: Modelo Punto de Vista de la Organización

46

En el modelo Punto de Vista de la Organización se establece la localización del sitio de los

laboratorios virtuales 3D en web 3.0 donde interactúan los actores como los Estudiantes y

Docentes de la Universidad.

Está referenciado como actor Salas Web Udistrital, su localización está dada en Bogotá, los

actores Estudiantes y Docentes intervienen según su función de relación como actores del

sistema en este punto se centrará el desarrollo del modelo de la arquitectura de software

que se describe más adelante, el actor estudiante y el Docente lleva una misma relación

de realización con el actor Salas Web Udistrital Virtuales indicando que su enlace es una

entidad lógica con una concreta (Figura 5.5).

47

5.1.2. Punto de Vista Cooperación de Actor

Figura 5.6: Metamodelo Punto de Vista Coperación del Actor

En el metamodelo punto de vista Cooperación del Actor hace parte de la capa de negocio

donde intervienen los objetos como: Colaboración, Servicio, Interfaz, Rol, Actor y Compo-

nente donde se relacionan dependiendo de sus respectivas funciones. La cooperación existe

con las partes externas como los actores, servicios y roles generando las funciones requeri-

das por el sistema siendo un proceso de negocio conjunto, el actor se enfoca en la relación

con el medio ambiente teniendo en cuenta lo que comúnmente se usa en la organización y

su entorno como clientes, proveedores y otros socios comerciales, proveyendo información

para determinar la colaboración y dependencia de dichas partes externas, para así generar

un proceso de funciones dentro de la aplicación interactuando con el servicio. (Figura 5.6).

48

Figura 5.7: Modelo Punto de Vista Cooperación del Actor

En el modelo Punto de Vista de Cooperacion del Actor intervienen varios actores y sus

diferentes medios de comunicación para asi llevar acabo las diferentes acciones y funciones

que lleva el sistema a la hora de realizar sus funciones. Los actores Facultades y Carreras

tienen una relación de agregación que con lleva a una serie características asignando roles

dentro del sistema de Salas Udistrital Virtual, implementando servicios como Chat, Foro,

Email estos servicios se relacionan por la realización conjunta y de colaboración para el

sistema (Figura 5.7).

49

5.1.3. Punto de Vista de Función de Negocio

Figura 5.8: Metamodelo Punto de Vistade Función de Negocio

Este metamodelo Punto de Vista de Función de Negocio se compone por los siguientes

objetos: Actor,Rol,Función, está relacionado con el manual de procedimientos que tiene una

organización y su negocio donde cada uno de los actores tiene su función especifica, siendo

usados para establecer aspectos de las actividades dentro de la organización. Asi el punto

de vista de función de negocio proporciona una visión para identificar las competencias

necesarias y estructuradas es la misma del metamodelo Punto de Vista de Función de

Negocio participan el actor, el rol y la función el actor se le asigna un rol y este rol tiene

una relación con la función del actor en el sistema , La función de negocio establece el

comportamiento que tiene el sistema hacia la organización (Figura 5.8).

50

Figura 5.9: Modelo Punto de Vista de Función de Negocio

El modelo Punto de Vista Función del Negocio los actores son los Estudiantes y los Docentes

donde la acción esta dada por la utilización del Laboratorio Virtual para realizar los trabajos

que se asignan en cada una de las clases de la materia establecida por el Docente, lo

particular es que en el sistema cada actor tiene una relación que asigna las funciones para

el Estudiante, Docente, Facultad. El funcionamiento del sistemas esta dado por la función

del negocio en este caso se desarrolla las actividades como verificar el pensum académico,

de acuerdo a esté se da los temas de cada materia y asesorías para así utilizar de forma

adecuada los laboratorios virtuales (Figura 5.9).

51

5.1.4. Punto de Vista de Proceso de Negocio

Figura 5.10: Metamodelo Punto de Vista Proceso de Negocio

En este punto de vista de Proceso de Negocio tiene como función obtener información

sobre los procesos de la organización donde el actor tiene asignado un rol y a su vez

una localización dentro de la organización donde también conceptos relacionados de los

servicios que se puede ofrecer en el mundo exterior, el metamodelo tiene como punto de

referencia la función del negocio que está asignada el actor y esté a su vez se le asigna al rol

donde se agrega como colaboración del negocio especializando el rol, donde la función del

proceso de negocio puede ser usado por el servicio de negocio donde el servicio del negocio

tiene acceso al objeto del negocio llevando a la localización (Figura 5.10).

52

Figura 5.11: Modelo Punto de Vista Proceso de Negocio

En este modelo esta relacionado con el actor Docente donde se verifica, el estado del

Laboratorio Virtual, la asignación y el permiso de ingreso para ser uso del medio, Para

lograr este ambiente, se hace uso de la plataforma de software que se denomina Aula

Virtual Laboratorio que permite que cada participante cuente con una representación gráfica,

denominada AVATAR, de forma que la presencia y posibilidad de interacción virtual, emule

en algún grado una situación real en el laboratorio virtual. En general permite recrear la

ambientación que represente espacios, aulas, edificios, en donde se pueden desarrollar

actividades de aprendizaje, de diversión, de socialización o de inmersión en una situación

específicamente graficada y estructurada donde cada usuario puede crear eventos según su

criterio o tomar decisiones frente a eventos previamente pre-establecidos (Figura 5.11).

53

5.1.5. Punto de Vista de Cooperación de Proceso de Negocio

Figura 5.12: Metamodelo Punto de Vista Cooperación de Proceso de Negocio

En este punto de vista es similar al proceso de negocio, tiene como función mostrar las

relaciones de uno o mas procesos de negocio con su entorno, implicando el o los servicios

que tiene la organización el metamodelo del punto de vista de proceso de negocio tiene

como punto central función del negocio, se tendrá una asignación con el rol y el rol tendrá

una asignación con el actor que a su vez el actor tendrá una asignación con la localización

de la organización, el rol puede agregar colaboración del negocio,donde se especializa al

rol, la función de negocio puede tener un flujo un disparo con la interacción del negocio, es

usado por el servicio de aplicación(Figura 5.12).

54

Figura 5.13: Modelo Punto de Vista Proceso Cooperación de Negocio

En este modelo esta relacionado con el Actor Estudiante, donde se verifica: Los permisos

de acceso al Laboratorio Virtual, la asignación de Talleres que se deben de realizar en la

materia dada por el Docente.

Su localización se basa en Salas Web Udistrital Virtuales, la experiencia educativa en los

laboratorios físicos puede ser significativa en el sentido en el que el mundo virtual permite

que los profesores hagan tutorías virtuales sin necesidad de tener un encuentro cara-cara

con el estudiante y eso llega a ser favorable en los casos que un encuentro personal con el

profesor representa una barrera en el proceso de aprendizaje, en el modelo se establece la

forma mas sencilla de hacer uso del Laboratorio para realizar las actividades correspondiente

(Figura 5.13).

55

5.1.6. Punto de Vista de Producto

Figura 5.14: Metamodelo Punto de Vista de Producto

En este punto de vista se relaciona la capa de negocio y la capa de aplicación, el punto de

vista de producto se establece una relación entre el rol del negocio y el de rol de servicio

donde el valor del producto es ofrecido a los clientes mediante contratos y acuerdos de

la organización estos dos componentes entran una relación mediante una interface de

aplicación el proceso de negocio puede tener una realización con el servicio donde es usado

por el proceso de negocio, el actor de negocio se relaciona por una asignación con el rol de

negocio y el proceso de negocio, el valor tiene acceso bidireccional con el producto y el

servicio (Figura 5.14)

56

Figura 5.15: Modelo Punto de Vista de Producto

En este modelo esta con el enfoque de capa de negocio, el producto central es el Laboratorio

Virtual donde su función es estar disponible para realizar las diferentes procedimientos a

la hora de su utilización. (Figura 5.15). Implementando el aprendizaje colaborativo, los

estudiantes van elaborando y modificando sus conocimientos por medio de un proceso de

intercambio y confrontación de sus comprensiones, siendo asesorados por una persona

con experiencia en este caso el docente llevando la utilización del laboratorio virtual a un

excelente uso.

57

5.1.7. Punto de Vista de Comportamiento de la Aplicación

Figura 5.16: Metamodelo Punto de Vista de Comportamiento de la Aplicación

En el punto de vista de comportamiento de la Aplicación pertenece a la capa de aplicación,

donde la Función de la aplicación tiene una relación bidireccional de flujo y de disparo

en la interacción de la aplicación para producir un evento entre ellos, la Función de la

aplicación también tiene una relación bidireccional con el servicio de la aplicacion llevando a

relacionarse con los objetos de datos, la Función de la aplicación se asigna a los componentes

de la aplicación donde se generaliza y se realiza con la colaboración de la aplicación, asi se

muestra el comportamiento del sistema, los actores tales como la colaboración de aplicación

asigna a una interfaz de interacción de aplicación llevan un flujo bidireccional y una relación

de disparo bidireccional con la función de aplicación, el componente de aplicación puede

tener asignación con la función de aplicación, y este se relaciona con la colaboración de

aplicación,la interacción de aplicación y función de aplicación, el servicio de aplicación

tienen acceso en una sola vía al objeto de datos. (Figura 5.16).

58

Figura 5.17: Modelo Punto de Vista de Comportamiento de la Aplicación

El modelo de comportamiento de la aplicación su componente central es el Taller Laborato-

rios Virtuales donde se relaciona con el componente Salas Web Udistrital Virtual donde las

funciones se basan en llevar acabo la realización de la clase y la realización de los trabajos

o talleres que se dejan.

Las funciones dadas para cada componente se basan en la función del negocio llevando

a una estrategia de aprendizaje colectivo colaborativo los estudiantes van elaborando y

modificando el conocimiento por medio de un proceso de intercambio de confrontación de

sus compresiones(Figura 5.17).

59

5.1.8. Punto de Vista de Cooperacion de Aplicación

Figura 5.18: Metamodelo Punto de Comportamiento de Aplicación

En el metamodelo punto de vistas de Cooperación de la Aplicación describe las relaciones

que existen entre los actores, servicios, componentes interactuando cada uno de ellos

llevando una colaboración mutua para asi obtener una visión general de la organización y

su localización que es un componente de la capa de negocio la interface es usado por un

componente donde la función tiene flujos interactuando de una forma bidireccional donde

tendrá una asignación con la interacción. (Figura 5.18).

60

Figura 5.19: Modelo Punto de Vista Proceso De Negocio

El componente central es Salas Web Udistrital Virtuales, donde interactúan con cada

componente: Publicación, Universidad, en el área de usabilidad y en el área de diseño de

datos con los componentes Taller y Horarios teniendo cada uno de ellos una localización en

la organización. Estableciendo con este modelo prácticas pedagógicas que estarán diseñadas

para ayudar a los estudiantes a pensar reflexivamente y realizar sus tareas correspondientes

al área de estudio, apropiándose de su proceso de aprendizaje y entendiendo la lógica de los

argumentos donde sus docentes ayudaran a construir esos conocimientos. (Figura 5.19).

61

5.1.9. Punto de Vista de Estructura de Aplicación

Figura 5.20: Metamodelo Punto de Vista de Estructura de Aplicación

Este punto de vista pertenece a la capa de aplicación, donde interecatuan los objetos de datos

con los componentes de la aplicación y los componentes de la aplicación tiene una relación

bidireccional con los componentes de la aplicación para asi mostrar el comportamiento que

hay entre cada uno de ellos donde el objeto de datos se relaciona con la dependencia del

componente de aplicaión donde tendrán una relación mediante una interface de aplicación

para asi dar servicio al proceso del negocio mostrando su funcionalidad (Figura 5.20).

62

Figura 5.21: Modelo Punto de Vista de Estructura de Aplicación

En este modelo el componente central es Salas Web Udistrital Virtuales se relaciona con

cada una de las interfaces de cada componente como son: Horarios,Universidad, Taller,

Publicación para realizar sus funciones. prácticas pedagógicas están diseñadas para ayudar a

los estudiantes a pensar reflexivamente, apropiarse de su proceso de aprendizaje, entender la

lógica de los argumentos e interactuar con sus pares para construir conocimientos. (Figura

5.21).

63

5.1.10. Punto de Vista de Uso de Aplicación

Figura 5.22: Metamodelo Punto de Vista de Uso de Aplicación

En este punto de vista esta compuesto en la parte de la capa de Negocio por actores como:

objeto, evento, rol, proceso/función y en la capa de software compuesto por actores como:

objetos servicios colaboración, componente, interface cada uno de ellos se relacionan

dependiendo de su aplicación y su función para así identificas cada uno de los servicios que

existen en la organización (Figura 5.22).

64

Figura 5.23: Modelo Punto de Vista de uso de Aplicación

El actor Proceso/Función esta dado como Ingreso en el modelo de vista de uso de la

aplicación donde se relaciona con las actividades a usar en la aplicación relacionando

los componentes que se establecen en la organización, para cada componente estos se

basan en la función del negocio llevando a una estrategia de aprendizaje colectivo que los

estudiantes modificando el conocimiento por medio de un proceso de intercambio de sus

compresiones(Figura 5.23).

65

5.1.11. Punto de Vista de Infraestructura

Figura 5.24: Metamodelo Puntos de Vista Proceso de Infrestructura

En el metamodelo de Infraestructura se relaciona los recursos de software, recusos Fisicos,

recursos lógicos donde estos recursos interactuan entre si para llevar el funcionamiento del

sistema de la organización, la topología de la infraestructura del negocio, tiene actores de la

capa de negocio como la localización, y actores de la capa de infraestructura como artefacto,

función de infraestructura, servicios de infraestructura, interface de infraestructura, ruta

de comunicación, red, dispositivo, nodo, y sistema de software, la función de infraestruc-

tura tiene acceso al artefacto y realización a servicios de infraestructura asignada con el

dispositivo (Figura 5.24).

66

Figura 5.25: Modelo Puntos de Vista Proceso de Infraestructura

En este modelo esta relacionado con la capa de negocio en la localización ubicando cada uno

de los nodos como son Servidores SeconLife, Salas Web Udistrital Virtuales, DB SQUILE,

Servidores Windows Server 2012 R2, geográficamente dando la nocion de la topología

diseñada para la organización, esta topologia es dada de acuerdo con los requerimientos

dados, para la organización es importante tener cada uno de los componentes dados para asi

dar un buen servicio. (Figura 5.25).

67

5.1.12. Punto de Vista de Uso de Infraestructura

Figura 5.26: Metamodelo Puntos de Vista Uso de Infraestructura

En el metamodelo Punto de Vista Uso de Infraestructura, la Infraestructura se relaciona con

las aplicaciones llevando acabo el funcionamiento tanto para los servicios como para los

componentes determinando los requerimientos para el rendimiento de las aplicaciones que

se usan siendo asignadas en el sistema del software (Figura 5.26).

68

Figura 5.27: Modelo Puntos de Vista Proceso de Infraestructura

En el modelo punto de Vista Proceso de la Infraestructura contiene componentes en la capa

de de infraestructura y componentes en la capa de aplicación, el componente principal es

Salas Web Udistrital Virtuales que se relacionan en el nodo del Servidor Seconlife con

los componentes Publicación y Universidad, este a su vez se relaciona con el componente

Talleres del Nodo laboratorio y el Nodo Asignatura con el componente Horario para asi

establecer los servicios que se establecen en el momento que se llegue a se de utilidad el

sistema(Figura 5.27).

69

5.1.13. Punto de Vista de Estructura de Información

Figura 5.28: Metamodelo Puntos de Vista Estructura de Información

En el metamodelo Punto de Vista de Estructura de información esta dado por las capas

de Infraestructura, Aplicación y de negocio donde los actores estan establecidos por la

representación, objetos, artefactos y significado relacionados por una estrategia acoplada

en el sistema esto permitirá que cada cliente de la organización este satisfecho a la hora de

utilizar el servicio (Figura 5.28).

70

Figura 5.29: Modelo Punto de Vista Estructura de Información

En el modelo Punto de Vista Estructura de Información se relaciona con la capa de aplica-

ción, la capa de negocio y la capa de Infraestructura, cada actor como Estudiante Ubicación,

Asignatura van relacionados con los actores Horarios y Laboratorios Virtuales para estable-

cer las funciones que se realizan por los servicios que se da por el actor Tipos de Asignaturas

que se compone por el actor Salas Laboratorios Virtuales(Figura 5.29).

71

5.1.14. Punto de Vista de Realización del Servicio

Figura 5.30: Metamodelo Puntos de Vista Realización del Servicio

En este punto de vista Realización del Servicio se compone por actores de la capa de

aplicación y de negocio estos actores son: Servicio, Colaboración, Rol, Actor, Evento,

Objeto, Componente, Proceso/Función cada uno se relacionan dependiendo de la función

que presten hacia cada servicio y de sus procesos (Figura 5.30).

72

Figura 5.31: Modelo Punto de Vista Realización del Servicio

En el Modelo Punto de Vista de Realización del Servicio los actores están sujetos a las

funciones y o procesos que tiene cada uno de los actores como: Estudiantes, Salas de

Laboratorios, Horarios, Docentes, Asignación, Laboratorio Virtual para asegurar y establecer

las asesorías que se daran a los estudiantes de cada asignatura.(Figura 5.31).

73

5.1.15. Punto de Vista de Proceso de Capas

Figura 5.32: Modelo Puntos de Vista de Capas

En el modelo Punto de Vista de Proceso de Capas representa el resumen de la organización

donde se encuentra las capas de Negocio, Aplicación e Infraestructura cada una de ellas se

relacionan entre si aplicando el funcionamiento del servicio que se presta en los laboratorios

Virtuales(Figura 5.32).

74

5.1.16. Punto de Vista de Stakeholder

Figura 5.33: Metamodelo Punto de Vista de Stakeholder

En este Punto de Vista de Stakeholder esta dado por la Capa de Motivación donde los actores

Stakeholder, Objetivo, Manejador, Valoración se relacionan entre si para llevar acabo el

análisis de la matriz DOFA en la organización El punto de vista de Stakeholder permite

el análisis del modelo de los actores y manejadores internos y externos, para producir un

cambio y evaluación en términos de fortalezas, debilidades, oportunidades y amenazas,

describe los lazos de las metas iniciales de alto nivel como también las preocupaciones y

evaluaciones que puedan surgir, constituye la base para requisitos de ingeniería de procesos,

incluyendo derivación de requisitos, análisis de contribución en conflicto y objetivos (Figura

5.33).

75

Figura 5.34: Modelo Punto de Vista de Stakeholder

En este modelo Modelo Punto de Vista de Stakeholder esta dado por los actores Estudiante,

Docentes donde se especifica lo que debe realizar el sistema cuando se establece el funcio-

namiento del mismo llevar a cabo las tareas desde cualquier lugar por medio de la Web,

ahorrando tiempos y obteniendo los conocimientos que se dan a la hora de realizar los

laboratorio o talleres(Figura 5.34).

76

5.1.17. Punto de Vista de Realización de Objetivos

Figura 5.35: Metamodelo Punto de Vista Realización de Objetivos

En el Metamodelo Punto de Vista Realización de Objetivos los actores Objetivo, Requeri-

miento, Restricción, Principio se relacionan estableciendo los objetivos que se tienen de la

organización y el sistema El punto de vista de realización de objetivos permite delimitar

estos de una forma de alto nivel siendo los objetivos más concretos en concordancia con los

requisitos que describen las propiedades para alcanzar las finalidades, el refinamiento que se

debe usar para los objetivos generales y objetivos específicos, los objetivos se usa mediante

la relación de agregación, también los objetivos pueden ser modelados por el modelo de

refinamiento de acuerdo a los objetivos de requisito(Figura 5.35).

77

Figura 5.36: Modelo Punto de Vista Realización de Objetivos

En el modelo Punto de Vista Realización de Objetivos se relaciona cada uno de los actores

que se encuentran en el sistema donde se establece a donde se quiere llegar, para así

determinar las metas que se quieren alcanzar llevando a cabo la realización del core del

negocio , el sistema tendrá el funcionamiento como por ejemplo el Estudiante debe de

realizar sus trabajos a tiempo y de manera agradable(Figura 5.36).

78

5.1.18. Punto de Vista de Contribución

Figura 5.37: Metamodelo Punto de Vista de Contribución

En el Metamodelo Punto de Vista de Contribución los actores Objetivo, Principio, Re-

querimiento/Restricción tienen relaciones bidireccionales donde se analiza las posibles

restricciones que se vean afectadas en el sistema para así ser corregidas permitiendo al

diseñador modelar relaciones de influencia entre objetivos y requisitos, también permite

analizar el impacto que tienen metas de forma influyentes, para detectar errores entre obje-

tivos, también puede utilizarse después de definir metas generales y especificas segun el

objetivo y posiblemente en los requisitos, las relaciones de agregación y realización son

dados como una relación (Figura 5.37).

79

Figura 5.38: Modelo Punto de Vista Contribución

En el modelo Punto de Vista Contribución los actores son determinados por las funciones

dependiendo del objetivo que se tenga asignados a los mismos, para asi llevar acabo los

procesos del sistema, donde el actor estudiante sera el encargado que la aplicación funcione

correctamente sin tener la necesidad de esperar a que asignen aulas o estén sin asignar para

ser utilizadas de esta manera el sistema sera funcional e innovador(Figura 5.38).

80

5.1.19. Punto de Vista de Principios

Figura 5.39: Metamodelo Puntos de Vista de Principios

Puntos de Vista de Principios tiene establecido dos actores Objetivo y Principio donde

tienen relaciones bidireccionales y relaciones hacia si mismo, para asi tener conocimiento

del comportamiento del sistema permitiendo que se hagan análisis al modelar el diseño

del problema incluyendo los objetivos que motivan estos principios, también las relaciones

entre principios y sus objetivos que pueden ser moderadas y cómo pueden influir positiva o

negativamente en el desarrollo del mismo.(Figura 5.39).

81

Figura 5.40: Modelo Punto de Vista de Principios

En este modelo Punto de Vista de Principios esta dado por un objetivo de forma principal

que es llevar acabo la realización de los talleres de una forma eficaz y sin contratiempos

llevando al sistema a ser confiable y seguro(Figura 5.40).

82

5.1.20. Punto de Vista de Realización de Requerimientos

Figura 5.41: Metamodelo Punto de Vista de Realización de Requerimientos

En el Metamodelo Punto de Vista de Realización de Requerimientos se basa en tres actores

Objetivo, Requerimiento, Restricción donde el objetivo estará relacionando por los actores

Requerimiento y Restricción donde su función es mejorar el objetivo para dar un mejor

funcionamiento al sistema dando claridad de la realización de los requisitos del modelo

de los elementos centrales como agentes de negocios, servicios de negocios, procesos

de negocio, servicios de aplicaciones o componentes de la aplicación, en particular los

requisitos pueden resultar de refinar los objetivos, también puede utilizarse para mejorar los

requisitos en requisitos más detallados, y puede utilizar la relación de agregación(Figura

5.41).

83

Figura 5.42: Modelo Puntos de Vista de Realización de Requerimientos

En el modelo Puntos de Vista de Realización de Requerimientos tiene como objetivo

principal realizar los talleres de las asignaturas en un tiempo corto, donde los Estudiantes y

Docentes obtengan resultados satisfactorios(Figura 5.42).

84

5.1.21. Punto de Vista de Motivación

Figura 5.43: Metamodelo Punto de Vista Motivación

Metamodelo Punto de Vista Motivación Esta relacionado con el Punto de Vista Contribución

y Punto de Vista Stakeholder donde los actores como Valoración, Manejador Participante

estan asignado al Objetivo y los requerimiento y Principio están relacionados entre si y

también con relaciones bidireccionales para realizar los objetivos que tiene la organización

en el sistema (Figura 5.43).

85

Figura 5.44: Modelo Puntos de Vista Motivación

En el modelo Puntos de Vista Motivación esta dado con el actor Docente donde establece el

objetivo que se define para el uso del laboratorio virtual 3D el docente podrá desempeñar

su labor de enseñar sus conocimientos de forma fácil y clara como si se estuviera en el

laboratorio físico, donde uno de los objetivos es dar asesorías por medio de este sistema

ayudando a la universidad Francisco Jose de Caldas hacer competitiva con las demás

universidades. (Figura 5.44).

86

5.1.22. Punto de Vista de Proyecto

Figura 5.45: Metamodelo Puntos de Vista de Proyecto

En el metamodelo Puntos de Vista de Proyecto se relacionan tres capas Migración, Moti-

vación, Negocio donde se utiliza para el gestión del cambio del modelo donde el servicio

y el sistema deben de estar operativos sin posibles modificaciones durante el proceso de

gestión del cambio para asi dar gestión de cambio de la arquitectura del modelo, esto si la

arquitectura del proceso de migración es una versión anterior, por ende tendrá como objetivo

un reemplazo a un nuevo proceso de migración, si esto no se realiza se tienen consecuencias

en a través del tiempo y también en las estrategias de crecimiento a largo plazo, algunas

características que se deben tener en cuenta en este punto de vista son: Desarrollo total de la

organización de la arquitectura de la empresa es una tarea que puede llevar vario tiempo,

todos los servicios y sistemas deben permanecer operativos sin posibles modificaciones o

cambios en la arquitectura de la empresa durante los procesos de cambio (Figura 5.45).

87

5

Figura 5.46: Modelo Puntos de Vista Proceso De Negocio

En Modelo Puntos de Vista de Proceso Está compuesto por Un paquete principal donde se

encuentran los actores como: Salas Web Udistrital Virtual, Magister, Docentes, Estudiantes,

Universidad donde interactuan dependiendo de las funciones establecidas por el sistema

(Figura 5.46).

88

5.1.23. Punto de Vista de Migración

Figura 5.47: Metamodelo Punto de Vista de Migración

En el metamodelo Punto de Vista de Migración se presentan dos actores brecha y platea,

donde la brecha tiene como función informar las mejoras del sistema de la primera versión,

y la platea su función es preparar la aplicación para ser Liberada esto implica modelos

conceptos que pueden utilizarse para especificar transiciones de una arquitectura existente a

una arquitectura deseada(Figura 5.47).

89

Figura 5.48: Modelo Punto de Vista de Migracion

El modelo Punto de Vista de Migración existen tres actores Salas Web Udistrital Virtuales,

Lab_Virtual, Docente Virtual, donde Salas Web Udistrital Vituales es el primer liberable,

y Lab_Virtual, Docente Virtual son itos que se implementan para ayudar al sistema, y las

brechas son las soluciones que se dan para el manejo del sistema(Figura 5.48).

90

5.1.24. Punto de Vista de Migración e Implantación

Figura 5.49: Metamodelo Punto de Vista Migración e Implantación

En el metamodelo Punto de Vista de Migración e Implantación esta diseñado con tres capas

que son: Aplicación, Motivación, Migración, los actores Actor, Rol, Localización Paquete

de trabajo, Liberable, Requerimiento/restricción, objetivo, Brecha, platea que se encuentren

en las capas mencionadas están relacionadas dependiendo de la función que se le establezca

permitiendo el alcance que tiene el sistema.(Figura 5.49).

91

Figura 5.50: Modelo Punto de Vista de Migración e Implantación

En el Modelo Punto Vista de Migración e Implantación se encuentran los actores en la

localización www.SalasWebUdistritalVirtuales, Salas Web Udistrital Virtual que esta como

la aplicacion liberable, siendo el plan de evolución, el paquete de de trabajo que es la

construcción del Laboratorio Virtual,teniendo el requerimiento de dictar las clases de cada

asignatura sin contratiempos asignado al actor Docente, para dar inicio a la implantación, se

establece la migración del sitio Salas Web Udistrital Virtual siendo liberabley a su vez el

gancho del negocio de la organización, es donde se encuentra módulos para hacer mejoras

al sistema(Figura 5.50).

92

5.2. Modelamiento de Patrones del Prototipo Aulas Vir-

tuales 3D

5.2.1. Patron Singleton Aplicado

Figura 5.51: Convierte la interface de una clase en otra interface que el cliente espera

El patron singleton se basa en comprobar la disponibilidad de las Aulas Vituales para ser

reservada por el Docente.

93

5.2.2. Patron Constructor Aplicado

Figura 5.52: Favorece el ensamble de productos complejos separando creación representa-

ción

El patrón constructor se basa en construir las funciones y titulo que tienen los docentes para

llevar a cabo la exposición de su materia.

94

5.2.3. Patron Fabrica Abstracta Aplicado

Figura 5.53: Favorece a creación de familia de productos.

El patrón Fabrica Abstracta se basa en construir Avatar en los mundos virtuales para que los

estudiantes y los docentes tengan una identificación llevando a cabo la utilización de los

laboratorios que se asignan.

95

5.2.4. Patron Fabrica Aplicado

Figura 5.54: Define una interface para crear un objeto, que de posterga a sus subclases

El patrón Fabrica Abstracta se basa en construir los mundos virtuales para que interactuen

los estudiantes y los docentes llevando a cabo la utilización de los laboratorios que se

asignan.

96

5.2.5. Patron Prototipo Aplicado

Figura 5.55: Especifica la clase de objetos a crear usando una instancia prototípica par crear

nuevos objetos, que de posterga a sus subclases

El patron Prototipo se basa en asignar un código único al estudiante para el ingreso al

servicio del Laboratorio virtual web, así se dará la seguridad en el sitio.

97

5.2.6. Patron Adaptador Aplicado

Figura 5.56: Define la creación de una sola instancia

El patrón Adaptador crea el entorno del Laboratorio Virtual según la función dada por el

estudiante, el patrón sera asignado en el sistema del software para ejecutar el manejo del

patrón

98

5.3. Montaje y Elaboración del Metaverso

En esta sección se asume que el lector tiene los conocimientos necesarios para interactuar

con Windows en la distribución de su preferencia, por lo tanto no se hace una descripción

detallada de los comandos necesarios para llevar a cabo cada paso ni la gestión de los

permisos de usuario en el proceso descrito.

Instalación de OpenSim

Debido a que OpenSim es un simulador multiplataforma, en la página están disponibles

los archivos para Windows, Linux o MAC OS. En este caso el montaje del servidor se hizo

en la distribución de Windows 7 pero también ha sido probado en versiones anteriores de

Ubuntu y en OpenSUSE. Es recomendable realizar el montaje del servidor en una versión

de Windows de 32 bits, ya que las versiones de 64 bits suelen presentar problemas de

compatibilidad con OpenSim y sus dependencias.

Los Archivos necesarios para el montaje de OpenSim en cualquier ordenador se encuentran

disponibles en la página oficial. A la fecha en que se escribe este documento, la última

versión es la 0.7.6.

OpenSim está desarrollado para correr sobre la plataforma .NET de Microsoft ya que gran

parte de su código así como los scripts que se utilizan en los metaversos están basados en

C#. Una vez el archivo de OpenSim se puede iniciar el servidor escribiendo el comando

“mono OpenSim.exe” en la consola y ubicado en la carpeta “bin” de OpenSim.

Si no hay ningún problema de compatibilidad se debe iniciar el servidor, el cual carga una

a una todas las dependencias necesarias para el metaverso. Si es la primera vez se corre

OpenSim en el ordenador, no se tendrá ningún metaverso creado para iniciar, por lo que

el simulador solicitara la creación de un metaverso, pidiendo los datos que se relacionan a

continuación:

New region name [ ]: Carácter alfanumérico. Nombre que se le va a dar a la región. Escribir

el nombre deseado para la región.

99

Region Location [1000,1000]: Coordenada x,y. Es el punto dentro de un plano coordenado

que queremos para nuestra región. Se debe especificar en modo Grid para no sobreponer la

región sobre regiones existentes. En caso contrario se puede aceptar el punto que viene por

defecto oprimiendo la tecla Enter.

InternalAddress [0.0.0.0]: Mascara Wildcard (dirección IP). Esta dirección es en realidad

una máscara wildcard que permite restringir el rango de direcciones que pueden acceder

al servidor. En la mayoría de los casos se debe dejar en 0.0.0.0 oprimiendo enter para que

todos los host puedan acceder. textfInternalPort [9000]: # de puerto (0 - 65535). Puerto

interno del servidor que se va a utilizar para el acceso. Si no se utiliza el puerto 9000 para

ninguna aplicación se puede oprimir enter para aceptarlo por defecto.

AllowAlternatePorts: Frue o False. Función aun en fase de experimentación. Se debe dejar

en “false” oprimiendo enter.

ExternalHostName: Dirección IP. Esta es la dirección con la cual los clientes van a acceder

al servidor, por lo cual se deben tener en cuenta algunas consideraciones que se explican

más adelante. Para iniciar se puede dejar en “SYSTEMIP”.

Do you wish to join region UDIN to an existing estate (yes/no)? [yes]: Esta opción se

utiliza para adherir la región recién creada a un estado existente, si existe algún estado

previamente creado al cual se quiera unir la región se debe escribir su nombre, si por el

contrario aun no existen estados se debe escribir “no” y proceder a crear uno.

Los parámetros que se piden para ser creados son:

Estate name [MyEstate]: Carácter alfanumérico. Un nombre cualquiera. Los siguientes

datos se deben tener presentes ya que con estos parámetros se crea un nuevo usuario dentro

100

del servidor y será el primer usuario en tener acceso al mismo.

Estate owner first name [Test]: Carácter alfanumérico. El nombre que se va a utilizar para

el propietario del estado.

Estate owner last name [User]: Carácter alfanumérico. El apellido que se va a utilizar

para el propietario del estado.

Password: Carácter alfanumérico. Contraseña del usuario creado.

Email: Carácter alfanumérico. Correo electrónico del usuario creado.

Con lo anterior se tiene ya una región, un estado y un usuario. Con esto ya se puede correr el

servidor y se puede acceder desde cualquier visor. Estos parámetros pueden ser modificados

en cualquier momento, accediendo con los permisos necesarios (modo root generalmente)

al archivo Regions.ini ubicado en la carpeta bin/Regions de OpenSim.

5.4. Modelo TMN-UIT o Modelo OSI

La UIT-T (Unión Internacional de telecomunicaciones- Sector de Normalización, antes

CCITT) publica en Abril de 1997 las recomendaciones M.3400, donde introduce el concepto

de TMN-UIT, para referir los 5 tipos de información manejada por los sistemas de gestión

de red, y aunque la UIT-T inicialmente lo desarrollo para asistir al manejo de las redes

de telecomunicaciones, fue la organización internacional de estandarización ISO quien

aplico este concepto a las redes de datos. ISO publico una estructura basada en TMN-UIT

denominada Open Systems Interconnect (OSI) Network Management Model, como la

guía básica para las implementaciones de administración de red. El modelo OSI agrupa

estos 5 tipos de información en las cinco áreas funcionales que caen bajo en ámbito de

101

lo que es la administración de red. Estas áreas son, “Fault Management, Configuration

Management, Accounting (or Asset/Inventory) Management, Performance Management,

and Security Management”. Por esta razón comúnmente también se conoce como el modelo

TMN-UIT. El modelo OSI presenta una arquitectura de gestión que permite supervisar,

controlar y mantener una red de datos, y para esto como se ha dicho se divide en cinco

categorías de servicios de gestión denominadas Áreas Funcionales Específicas de Gestión,

cuya denominación y funciones son:

Gestión de la configuración. La gestión de configuración comprende una serie de

facilidades mediante las cuales se realizan las siguientes funciones: -Iniciación y

desactivación. -definición o cambio de parámetros de configuración. -Recogida de

información de estado. -Denominación de los elementos de la red.

Gestión de prestaciones o rendimiento. Se define como la evaluación del compor-

tamiento de los elementos de la red. Para poder efectuar este análisis es preciso

mantener un histórico con datos estadísticos y de configuración.

Gestión de fallos Detección, diagnóstico y corrección de los fallos de la red y de

las condiciones de error. Incluye:

-Notificación de fallos -Sondeo periódico en busca de mensajes de error -Establecimiento

de alarmas

Gestión de contabilidad Determinación de los costes asociados a la utilización

de los recursos y la asignación de sus correspondientes cargas.

Gestión de seguridad Comprende el conjunto de facilidades mediante las cuales el

administrador de la red modifica la funcionalidad que proporciona seguridad frente

a intentos de acceso no autorizados. Incluye aspectos como la gestión de claves,

cortafuegos e históricos de seguridad.

En la arquitectura de gestión OSI se define un objeto gestionable como la interfaz

conceptual que han de presentar los dispositivos que ofrecen funciones de gestión.

102

El proceso de supervisión y control de un objeto gestionable se realiza mediante una

serie de interacciones. Estas interacciones son de dos tipos:

- De operación: el gestor solicita algún dato al objeto gestionable o desea realizar

alguna acción sobre él. - De notificación: cuando el objeto gestionable intenta enviar

algún dato al gestor como consecuencia de algún evento ocurrido en el dispositivo.

Un objeto gestionable se caracteriza además por un conjunto de atributos que son

las propiedades o características del objeto, y un comportamiento en respuesta a las

operaciones solicitadas. La comunicación entre el gestor y el objeto gestionable

no es directa, se realiza mediante un intermediario: el agente de gestión (esto

se corresponde con un modelo centralizado gestor- agente). La función del agente

es controlar el flujo de información de gestión entre el gestor y el objeto. Este

control lo realiza comprobando una serie de reglas de gestión (por ejemplo que el

gestor tenga la capacidad para solicitar una determinada operación), que han de

cumplirse para poder realizar la operación. Estas reglas se incluyen en los datos

como parte de la solicitud de una operación. * El flujo normal de información de

gestión y control entre el gestor y el agente se realiza mediante el protocolo CMIP,

perteneciente al nivel de aplicación OSI. * El protocolo permite que un sistema

se pueda configurar para que opere como gestor o como agente. La mayoría de

las realizaciones prácticas de sistemas gestionados se configuran con unos pocos

sistemas operando en modo gestor, controlando las actividades de un gran número de

sistemas operando en modo agente. *Cuando dos procesos se asocian para realizar

una gestión de sistemas, deben establecer en qué modo va a operar cada uno de ellos

(en modo agente o en modo gestor). Los procesos indican, mediante las denominadas

unidades funcionales, qué funcionalidades de gestión y estándares utilizarán durante

la asociación. Otros componentes de la arquitectura de gestión OSI son: Estructura

de la Información de Gestión (Structure of Management Information, SMI).

Define la estructura lógica de la información de gestión OS. Base de Información de

Gestión (Management Information Base, MIB). Representa la información que se

está utilizando, modificando o transfiriendo en la arquitectura de los protocolos de

103

gestión OSI. CMIS (Common Management Information Services) es un conjunto

de reglas que identifican las funciones de una interfaz OSI entre aplicaciones.

5.5. Protocolo de acceso Opem Sim y la Web Semantica

(Web 3.0) en el proyecto GLORIA

Figura 5.57: Modelo Capas Web Semantica

El protocolo de acceso utilizado en el prototipo desarrollado se basó en el modelo de nueve

capas de la web semántica tomado del modelo de las 7 capas de Tiem Berners Lee, que

son dados en la Figura 4.11, considerándose un mecanismo para obtener una adecuada

definición de los datos o metadatos que en el proyecto GLORIA provee de las observaciones

que se obtienen integrando a su vez opemsim adaptando el protocolo RST2 que emplea la

comunicación basada en cadenas ASCCII a través de sockects TCP/IP teniendo la habilidad

104

para cambiar a modo binario para transferir datos, imágenes y otros tipos de datos, y realizar

la operatividad de los dispositivos.

El modelado de los objetos 3D se realiza visualmente desde el mismo Viewer, contando

para ello con un modo Construir. Para programar el comportamiento de estos objetos ante

los eventos que ocurran en su entorno, Open Sim ofrece la posibilidad de asociar uno o más

scripts a cada objeto. Estos scripts deben estar escritos en Linden Scripting Language (LSL)

[48], un lenguaje inventado por los creadores de Opem Sim directamente orientado a la

gestión de estados y eventos. Es importante destacar que, aunque los scripts se desarrollan

en el Viewer, su ejecución se lleva a cabo siempre en los servidores de Opem Sim. Por tanto,

cualquier comunicación establecida con la red externa desde un script LSL tendrá como

origen un servidor de Opem Sim, y nunca el ordenador del usuario. En WebUdistrital, los

mecanismos de comunicación que ofrece Opem Sim con la red externa en la conexión y el

comportamiento del laboratorio deben de estar LSL (Linden Scripting Language), que ofrece

en su API la utilización de dos solo dos protocolos: XML-RPC: La implementación de este

protocolo [43] únicamente permite responder a peticiones iniciadas en el exterior, por lo que

la comunicación nunca puede ser iniciada desde el propio script LSL. Además, las funciones

ofrecidas sólo permiten la devolución de un valor de tipo integer y/o un valor de tipo string

como por ejemplo el ingreso del usuario y la contraseña del usuario para inicializar el

uso del laboratorio virtual. HTTP [44]: Permite programar tanto servidores como clientes

HTTP, pudiendo iniciar las comunicaciones tanto desde el propio Opem Sim como desde

la red externa [49]. Un elemento a destacar es que Open Sim añade automáticamente una

serie de cabeceras a todas las peticiones realizadas desde él, incluyendo información tanto

relativa al objeto propietario del script que realiza la petición como al personaje que ha

provocado el evento que ha dado lugar a la petición. Para el ingreso al portal WebUdistrital

los usuarios deben de ser creados en el sistema GLORIA y a su vez sean sincronizados con

el sistema Open Sim , para que la validación sea satisfactoria en el sistema Opem Sim , el

cliente es ejecutado directamente desde el servidor Opem Sim accediendo al laboratorio

Astronomía y hacer uso de los recursos de la red de telescopio GLORIA Por último, Opem

Sim ofrece la posibilidad de insertar un componente multimedia en en el mundo virtual,

105

que puede ser utilizado como textura de cualquier objeto. Dicho componente multimedia

puede ser un archivo de audio (audio/*), una imagen (image/*), un video en streaming

(video/*) o página web (text/html). En el entorno no ha causado una ruptura con el diseño

como tal, sino una implementación más incompleta de lo previsto. El diseño propone a la

implementación completa del protocolo XML-RPC, entendiéndose que el protocolo delegue

el soporte de HTTP ofrecido por LSL las funciones de transporte. La realidad es que lograr

una implementación completa del protocolo es técnicamente imposible, puesto que Opem

Sim impone una limitación de 64 KB de memoria en el entorno de ejecución de los scripts

LSL [45]. Dichos 64 KB de memoria incluyen toda la memoria necesaria para la ejecución

del script: bytecode, stack y heap. Además, la compilación que Opem Sim hace del código

LSL genera un bytecode sorprendentemente grande donde al ejcutar mas de 100 líneas de

código fuente del protocolo RST2 consumen los primeros 55-60 KB de memoria. En estas

condiciones, la implementación que se ha realizado del protocolo ha tenido que ser parcial,

limitada a las necesidades de uso imprescindibles para el funcionamiento del actual Cliente

el funcionamiento de los dispositivos que se establecen en GLORIA.

106

Capítulo 6

Conclusión

En este trabajo se ha descrito la primera red mundial de telescopio robótico, el cual tiene

la intención de dar a los usuarios el acceso gratuito a una red de 17 telescopios robóticos

distribuidos en 4 continentes y los dos hemisferios donde tras la realización del prototipo es

clara y no siempre se da en proyectos de carácter innovador: se ha conseguido el objetivo

propuesto y por tanto la idea inicial es viable. Se ha logrado integrar una experiencia con el

proyecto gloria y la web 3.0 en un laboratorio remoto, en un entorno de acceso 3D sobre una

plataforma de carácter social como Opem Sim. Conforme al desarrollo logrado no es más

que un prototipo, y por tanto las limitaciones encontradas durante la implementación deben

ser tenidas muy en cuenta a la hora de transformar este prototipo en un producto final., ya que

Opem Sim no es una plataforma muy viable para realizar desarrollos con grandes cantidades

de datos para ser procesados ya que el uso de recursos de hardware son de bastante consumo.

Este proyecto ha tenido que sortear dificultades no esperadas, y todas ellas se deben a las

limitaciones técnicas que impone la herramienta. Resumidamente se han manifestado la

siguiente dificultad donde el lenguaje LSL limita la gestión en memoria de estructuras de

datos ya que no ofrécele la implementación de la programación orientada a objetos , el tipo

de dato que ofrece son las listas (List) donde permite gestionar elementos de colecciones de

cualquier tipo pero donde estas listas no soportan anidamiento ósea llamadas de funciones o

procedimientos por lo que el uso de estructuras de niveles se vuelve en una dificultad para

107

ser solucionado de cierta manera como también el uso de memoria es muy limitado siendo

de 64 KB en su totalidad a la hora de realizar los llamados de los Script LSL en la cabecera

de del sitio WEB 3.0 (WebUdistrital) y al ser uso de los elementos del laboratorio el sistema

produce bloqueos quedando congelado no quiere decir que la transformación del prototipo

logrado en un producto de verdad sólo es posible si se elige una tecnología distinta a Opem

Sim como entorno de acceso al laboratorio remoto si no que se debe de llevar a acabo como

proyecto a futuro una forma de buscar un protocolo que nos permita mitigar estas fallas ya

que la web 3.0 se está desplegando en el mundo virtual para así ser uso concepto de Web

3D pero con el uso de herramienta CSS3 podemos crear transformaciones que utilizan la

tercera dimensión y el HTML5 comienza a incorporar avances en este sentido. De manera

más avanzada se está creando WebGL, una especificación estándar para mostrar gráficos

3D acelerados por hardware en páginas web y poder integrarlos con los mundos virtuales

realizados en Opem Sim.

108

Bibliografía

[1] Red Clara. Bogotá Colombia. http://www.redclara.net/index.php?option=

com_content&view=article&id=3&Itemid=387&lang=es

[2] Red Universitaria Metropolitana de Bogotá (RUM-

BO). Bogotá Colombia. http://www.renata.edu.co/

index.php/component/content/article/3-que-es-renata/

453-rumbo-red-universitaria-metropolitana-de-bogota.html

[3] Red Nacional Académica de Tecnología Avanzada (RENA-

TA). Bogotá Colombia. http://www.renata.edu.co/index.php/

quienes-somos-identidad-y-objetivos-de-renata.html

[4] Centro de Computación de Alto Desempeño (CECAD). Bogotá Colombia.

http://cecad.udistrital.edu.co/index.php?option=com_content&view=

article&id=4&Itemid=2

[5] ROSENBERG, M. J. (2000). E-Learning: Strategies for Delivering Knowledge in the

Digital Age. New York: McGraw-Hill Professional Publishing

[6] HARTLEY, D. E. (2000). On-Demand Learning: Training in the New Millennium.

Boston, MA: HRD Press.

[7] Red de Investigación de Tecnología Avanzada (RITA). Bogotá Colombia.

http://cecad.udistrital.edu.co/index.php?option=com_content&view=

109

article&id=35:red-de-investigaciones-de-tecnologia-avanzada-rita&

catid=18:redes-de-investigacion

[8] OpenSim un mundo virtual 3D Libre. Guillermo Gallegos Candela. http://www.

slideshare.net/guillermo/opensim-presentation

[9] Barrio, R., Parrondo, J., Blanco, E., & Fernández, J. (2011). Introducción de labora-

torios virtuales en la enseñanza no presencial mediante entornos de trabajo propios.

Revista de Formación e Innovación Educativa Universitaria. Vol. 4.

[10] Bottentuit Junior, J. B., & Clara, C. (2007). Virtual Laboratories and M-Learning:

learning with mobile devices. Proceedings of International Milti-Conference on Society,

Cybernetics and Informatics.

[11] Budhu, M. (2002). Virtual Laboratories for Engenieering Education. International

Conference on Engineering Education, Manchester, UK.

[12] Catlin, A., Gaitatzes, M., Houstis, E., Ma, Z., Markus, S., Wang, N.-H., & Weerawa-

rana, S. (25 de Noviembre de 2012). The SoftLab Experience: Building Virtual Labo-

ratories for Computational Science. http://www.cs.purdue.edu/research/cse/

softlab/softlab-vlabs/softlab-framework/softlab_report/report.html

[13] Convenio específico de Colaboración y mutua ayuda entre la Institución Univer-

sitaria de Envigado y la Fundación Universitaria Luis Amigó No. 50. (23 de Ju-

lio de 2012). Colombia Aprende - Ministerio de Educación Nacional - República

de Colombia. http://www.colombiaaprende.edu.co/html/investigadores/

1609/w3-article-297504.html

[14] Crespo Madera, E. J., Álvarez Vizoso, T., & Bernaza rodríguez, G. (2005).

Las prácticas de Laboratorio Docentes en la Enseñanza de la Física.

http://www.utchvirtual.net/recursos_didacticos/documentos/fisica/

practicas-laboratorio.pdf

110

[15] Cumbrera, R. (2007). El desarrollo de la actividad experimental en física general y el

uso de las tics en las prácticas de laboratorio. Revista Pedagogía Universitaria.

[16] Debel, E., Cuicas, M., Casadei, L., & Alvarez, Z. (2009). Experimento real y simulación

como herramientas de apoyo para lograr aprendizajes. Multiciencias, Vol. 9.

[17] Dumon, A. (1992). Formar a los estudiantes en el método experimental: ¿Utopía o

problema superado? Enseñanza de las Ciencias

[18] Feisel, L., & Rosa, A. (2005). The Role of the Laboratory in Undergraduate Enginee-

ring Education. Journal of Engineering Education.

[19] Alarcón, R. (2000). UML Diseño Orientado a Objetos con UML. Madrid, España:

Grupo Eidos S. L.

[20] Archimate 2.0

[21] Ibarra B., C. A., Medina S., S., & Bernal N., Á. (2007). Implementación de un

laboratorio virtual para el estudio de dispositivos electrónicos. TE & ET; no. 2.

[22] M. Bertogna, E. Grosclaude, R. del Castillo, F. Lopez Luro, C. Zanellato CACIC

(2005)..Arquitectura para Laboratorios Remotos Físicos y Virtuales".

[23] Grosclaude Eduardo, Bertogna Leandro, Lopez Luro Francisco, Zanellato Claudio,

Sánchez Laura, Rodríguez Jorge, Del Castillo Rodolfo, La Plata (2006). .Experiencia

con Laboratorio Remoto Colaborativo". Exposición y Demostración.

[24] https://www.researchgate.net/publication/263787323

[25] http://www.cs.vu.nl/ eliens/media/paper-secondlife.html

[26] Grosclaude Eduardo, Bertogna Leandro, Lopez Luro Francisco, Zanellato Claudio,

Sánchez Laura, Rodríguez Jorge, Del Castillo Rodolfo, La Plata (2006). .Experiencia

con Laboratorio Remoto Colaborativo". Exposición y Demostración.

111

[27] Massively Multi-Learner: Recent Advances in 3D Social Environments». Computing

and Information Systems Journal, vol. 10, n.o 2. Accedido el 16 de agosto de 2006 a

través de http://www.cis.paisley.ac.uk/research/journal/v10n2/LivingstoneKemp.doc.

[28] http://gloria-project.eu/about-es/

[29] HENAO, CLARA. “Aprendizaje Colaborativo en Ambientes Sincrónicos y Asincróni-

cos”. Maestría de Tecnologías de la Información Aplicadas a la Educación. Universidad

Pedagógica Nacional. Bogotá, Colombia. 2008

[30] A. J. Castro-Tirado et al,” The GLObal Robotic telescopes Intelligent Array for

e-science (GLORIA)”

[31] Castro-Tirado, A. 2010, Robotic Astronomy 2009, A. J. Castro-Tirado, J. S. Bloom, L.

Hanlon and T. Kotani (eds.), Advances in Astronomy, vol 2010

[32] T. Earl: SOA Design Patterns. Prentice Hall (2009)

[33] R.B. Denny: Dispatch Scheduling of Automated Telescopes. The Society for Astrono-

mical Sciences 23rd Annual Symposium on Telescope Science, CA. Published by the

Society for Astronomical Sciences, p.35. (2004)

[34] C.J. Mottram, S.N. Fraser: Robonet-1.0. Astronomical Notes Volume 329, Issue 3,

pages 317-320 (2008)

[35] A. R. Duncan: Federating access to small-aperture telescopes. International Confe-

rence on eScience, pp. 8 to 14 (2010)

[36] Z. Y. Chaowang Shang: SAML Based Unified Access Control Model for Inter-Platform

Educational Resources. In: International Conference on Computer Science and Software

Engineering, 2008 pp. 909 to 912.

[37] eduGain, www.geant.net

[38] European eID Interoperability Platform, www.eid-stork.eu.

112

[39] LifeRay Portal, www.liferay.com

[40] GLORIA Youtube Channel, www.youtube.com/user/gloriaproject

[41] R. Sezov, Jr.: Liferay in action. Manning, pp. 167-175 (2012)

[42] R. Buyya, D. Abramson, J. Giddy, H. Stockinger: Economic models for resource mana-

gament and scheduling in Grid computing. Concurrency Computation: Practice and

Expe- rience, pp. 1507 - 1542 (2002)

[43] Opensim.Manual Support http://simtkconfluence.stanford.edu:8080/display/OpenSim/

[44] OpenSim un mundo virtual 3D Libre. Guillermo Gallegos Candela.

http://www.slideshare.net/guillermo/opensim-presentation

[45] Dynamic simulations of Multibody systems ,Springer New York, 2001.

[46] C.J. Mottram, S.N. Fraser: Robonet-1.0. Astronomical Notes Volume 329, Issue 3,

pages 317–320 (2008)

[47] T. Earl: SOA Design Patterns. Prentice Hall, Vesión 2009

[48] EduGain, www.geant.net

[49] GLORIA Youtube Channel, www.youtube.com/user/gloriaproject

[50] OM Telescope website, http://om.fi.upm.es

[51] R. Buyya, D. Abramson, J. Giddy, H. Stockinger: Economic models for resource mana-

gament and scheduling in Grid computing. Concurrency Computation: Practice and

Expe-rience, pp. 1507 – 1542

[52] TAD Telescope website, www.ot-tad.com

113