Deposito TFG Convocatoria Junio 2015

TRABAJO FIN DE GRADO

ESCUELA UNIVERSITARIA POLITÉCNICA

Departamento de Ciencias Politécnicas Grado en Ingeniería Informática

“Integración de ontologías en un sistema experto para la recomendación de recursos educativos en un LMS

(Learning Management System)”

Autor: D. Alberto Miguel Oliva Molina

Director: Dr. D. Alberto Caballero Martínez Director: Dr. D. Andrés Muñoz Ortega

Murcia, Junio de 2015

TRABAJO FIN DE GRADO

ESCUELA UNIVERSITARIA POLITÉCNICA

Departamento de Ciencias Politécnicas Grado en Ingeniería Informática

“Integración de ontologías en un sistema experto para la recomendación de recursos educativos en un LMS

(Learning Management System)”

Autor: D. Alberto Miguel Oliva Molina

Director: Dr. D. Alberto Caballero Martínez Director: Dr. D. Andrés Muñoz Ortega

Murcia, Junio de 2015

Dr. D. Alberto Caballero Martínez profesor de la UCAM.

Dr. D. Andrés Muñoz Ortega profesor de la UCAM.

CERTIFICAN: que el Trabajo Fin de Grado titulado “Integración de

ontologías en un sistema experto para la recomendación de recursos

educativos en un LMS (Learning Management System)” que presenta D.

Alberto Miguel Oliva Molina, para optar al título oficial de Grado en Ingeniería

informática, ha sido realizado bajo su dirección.

A su juicio reúne las condiciones necesarias para ser presentado en la

Universidad Católica San Antonio de Murcia y ser juzgado por el tribunal

correspondiente.

Murcia, a 1 de Junio de 2015

Dr. D. Alberto Caballero Martínez Dr. D. Andrés Muñoz Ortega

Agradecimientos.

Me gustaría expresar mi agradecimiento a todas las personas que han

hecho posible este trabajo. En especial a mis tutores, Alberto Caballero y

Andrés Muñoz, que han guiado y ayudado de forma excepcional al

desarrollo de este proyecto. Por su eterna paciencia y comprensión, a pesar

de los retrasos y dificultades que han acompañado este desarrollo, ellos

siempre dieron su apoyo y su soporte.

A mi familia, porque sin su apoyo, posiblemente, este proyecto y el grado

que culmina con su presentación, habrían quedado abandonados

indefinidamente.

A mis compañeros de carrera, Francisco y Daniel, que estuvieron a mi

lado en los peores momentos, apoyándome incondicionalmente.

Posiblemente el valor más destacable de mi paso por UCAM sea esta

amistad que me llevo.

A mi amigo Potter por haberme ayudado siempre sin pedir nada a cambio.

Gracias a todos.

RESUMEN

En el presente trabajo fin de grado se plantea e implementa un

sistema experto dentro de un LMS (Learning Management System), el

cual, mediante la combinación de la información del contexto y el uso de

conocimiento experto es capaz de proporcionar servicios de

personalización y recomendación dentro del mismo.

Para la representación del contexto de un LMS hemos creado una

ontología denominada “OntoSakai”. Esta ontología está formada, a su

vez, por cuatro ontologías, que representan, en conjunto, las diferentes

áreas del proceso de aprendizaje: competencias, usuarios, herramientas

de aprendizaje y clasificación semántica de los elementos de un LMS.

Proporciona, por tanto, un vocabulario estandarizado sobre los elementos

de un LMS y las actividades académicas realizadas dentro de esta

plataforma.

Esta combinación de conocimiento experto e información de contexto

puede ser fácilmente integrada con otros sistemas dentro del entorno

académico con el objeto de proporcionar interoperabilidad entre ellos.

Concretamente, en este trabajo, hemos integrado nuestro sistema con

Sakai, un conocido LMS para entornos universitarios. Como resultado de

esta integración, OntoSakai es capaz de recomendar recursos con el

objetivo proporcionar un beneficio tanto para el aprendizaje por parte del

alumno como facilitar y adaptar el proceso de enseñanza por parte del

personal docente.

En el desarrollo de este trabajo, analizamos la integración de

OntoSakai con el LMS mencionado. Para demostrar su correcto

funcionamiento hemos implementado una versión semántica de la

herramienta “Recursos” mediante un servicio Web que permite ofrecer

servicios de recomendación.

Palabras Clave: LMS, Ontología, servicio Web, Recomendación

Automática.

ABSTRACT

In current end-of-grade project an expert system within an LMS (Learning

Management System) is laid out and implemented. By combining the contextual

information and use of expert knowledge the system is able to provide

personalization and recommendation in it services.

To represent the user context within an LMS we have created an ontology

which we have called "OntoSakai". This ontology is formed, in turn, by four

subonthologies, which, together, represent the different areas of the learning

process: competences, users, tools for learning and semantic classification of

the elements of an LMS. Therefore, provides a standardized vocabulary about

the elements of an LMS and the academic activities carried out within this

platform.

This combination of expert knowledge and contextual information can be

easily integrated with other systems within the academic environment in order

to provide interoperability between them. Specifically, in this work, we have

integrated our system with Sakai, a famous LMS for university environments. As

a result of this integration, OntoSakai is able to generate user profiles that

facilitate customization of the use of the tools within the LMS, and is able to

recommend resources in order to benefit the student's learning as well as to

facilitate and adapt the process of teaching by teaching staff.

In the development of this paper, we analyze the integration of OntoSakai

with the aforementioned LMS. In order to demonstrate proper functionality we

have implemented a semantic version of the 'Resources' tool by using a web

service that can offer recommendations.

Keywords: LMS, Ontology, Web Service, Automatic Recomendation.

Índice de contenido

1. INTRODUCCIÓN ....................................................................................... 27

1.1 Motivación ........................................................................................... 27

1.2 Definición ............................................................................................ 30

1.3 Objetivos ............................................................................................. 32

2. ESTADO DEL ARTE.................................................................................. 33

2.1 Conceptos relevantes del dominio de la aplicación. ............................ 33

2.1.1 Sakai. ............................................................................................ 33

2.1.2 OntoSakai. .................................................................................... 34

2.2 Relación con proyectos con la misma funcionalidad. .......................... 36

2.3 Estudio de viabilidad. .......................................................................... 39

2.3.1 Alcance del proyecto. ................................................................... 39

2.3.2 Estudio de la situación actual. ...................................................... 41

2.3.3 Estudio y valoración de las alternativas de solución ..................... 44

3. METODOLOGIAS USADAS ...................................................................... 48

3.1 Recogida de requisitos: IEEE 830. ...................................................... 48

3.2 Modelado del sistema. ........................................................................ 50

3.2.1 Modelado de OntoSakai. .............................................................. 50

3.2.2 Modelado de OntoSakaiWS y las herramientas a integrar dentro

del campus. ............................................................................................... 51

4. TECNOLOGIAS Y HERRAMIENTAS USADAS EN EL PROYECTO ........ 57

4.1 Tecnologías empleadas. ..................................................................... 57

4.1.1 Desarrollo de la ontología. ............................................................ 57

4.1.2 Desarrollo de OntoSakaiWS. ........................................................ 59

4.1.3 Desarrollo de las herramientas integradas con Sakai. .................. 62

4.2 Herramientas empleadas. ................................................................... 64

4.2.1 Protegé. ........................................................................................ 64

4.2.2 Eclipse. ......................................................................................... 65

4.2.3 Apache Maven. ............................................................................. 65

4.2.4 Apache Tomcat. ............................................................................ 66

4.2.5 Sublime Text. ................................................................................ 66

4.2.6 DBVisualizer. ................................................................................ 67

5. ESTIMACIÓN DE RECURSOS Y PLANIFICACIÓN ................................. 69

5.1 Fases del proyecto. ............................................................................. 69

5.2 Estimaciones utilizadas. ...................................................................... 71

5.2.1 Estimación por puntos de función ................................................. 71

5.3 Planificación temporal del proyecto ..................................................... 78

5.4 Coste económico ................................................................................ 81

5.4.1 Costes materiales ......................................................................... 81

5.4.2 Costes humanos. .......................................................................... 82

5.4.3 Costes totales ............................................................................... 84

5.5 Valoración real de la dedicación ......................................................... 84

6. DESARROLLO DEL PROYECTO ............................................................. 89

6.1 Desarrollo de la Ontología OntoSakai ................................................. 89

6.1.1 Glosario de términos. .................................................................... 89

6.1.2 Taxonomías de conceptos ............................................................ 93

6.1.3 Diagrama de relaciones binarias .................................................. 96

6.1.4 Diccionario de conceptos ............................................................ 100

6.1.5 Detalle de las relaciones binarias ............................................... 101

6.1.6 Descripción de los atributos de instancia .................................... 102

6.1.7 Descripción de atributos de clase ............................................... 103

6.1.8 Descripción de las constantes .................................................... 103

6.1.9 Descripción de las instancias ..................................................... 103

6.1.10 Conclusiones OntoSakai ............................................................ 104

6.1.11 Implantación de la ontología en Protegé. ................................... 105

6.2 OntoSakaiWS .................................................................................... 108

6.2.1 Especificación de requisitos de software. ................................... 108

6.2.2 Diseño de la solución .................................................................. 117

6.2.3 Pruebas de esfuerzo ................................................................... 123

6.2.4 Despliegue .................................................................................. 124

6.3 OntoSakai Resources ....................................................................... 124

6.3.1 Especificación de requisitos de software. ................................... 124


6.3.3 Pruebas unitarias ........................................................................ 140

6.3.4 Despliegue .................................................................................. 141

6.4 OntoSakai Browser ........................................................................... 142

6.4.1 Especificación de requisitos de software .................................... 142


6.4.3 Despliegue .................................................................................. 156

7. PLAN DE PRUEBAS E INTEGRACIÓN .................................................. 157

7.1 Plan de pruebas ................................................................................ 157

7.1.1 Pruebas de integración ............................................................... 157

7.2 Integración de la solución .................................................................. 159

8. CONCLUSIONES .................................................................................... 161

8.1 Objetivos alcanzados ........................................................................ 161

8.2 Conclusiones del trabajo y personales .............................................. 161

8.3 Vías futuras ....................................................................................... 163

9. BLIBLIOGRAFIA ...................................................................................... 167

10. ANEXOS .............................................................................................. 173

10.1 Anexo A: Casos de uso ..................................................................... 173

10.1.1 Anexo A1: OntoSakaiWS ............................................................ 173

10.1.2 Anexo A2: OntoSakai Resources ............................................... 192

10.1.3 Anexo A3: Ontosakai Browser .................................................... 202

10.2 Anexo B: Diagramas de secuencia ................................................... 209

10.2.1 Anexo B1: OntoSakaiWS ............................................................ 209

10.2.2 Anexo B2: OntoSakai Resources ............................................... 220

10.2.3 Anexo B3: OntoSakai Browser ................................................... 225

10.3 Anexo C: Manual de instalación ........................................................ 231

10.3.1 Instalación LMS Sakai ................................................................ 231

10.3.2 Instalación de OntoSakaiWS ...................................................... 249

10.3.3 Instalación de OntoSakai Resources y OntoSakai Browser ....... 252

10.4 Anexo D: Manual de usuario. ............................................................ 258

10.4.1 OntoSakai Resources ................................................................. 258

10.4.2 OntoSakai Browser ..................................................................... 265

10.5 Anexo E: Especificación de Methontology ........................................ 268

10.5.1 Principales componentes de modelado: ..................................... 268

10.5.2 Tareas definidas por Methontology. ............................................ 269

Índice de figuras Figura 1. Estructura LMS ................................................................................ 28

Figura 2. Visión general de OntoSakai ............................................................ 36

Figura 3. Alcance del proyecto ......................................................................... 40

Figura 4. Aplicaciones más usadas en UCAM ................................................ 42

Figura 5. Desarrollo en cascada ...................................................................... 53

Figura 6. Modelo de desarrollo en espiral. ....................................................... 55

Figura 7. Modelo de desarrollo en cascada con prototipado rápido. ............... 56

Figura 8. Diagrama de Gantt General .............................................................. 79

Figura 9. Diagrama de Gantt real (A) ............................................................... 85

Figura 10. Diagrama de Gantt real (B) ............................................................. 85

Figura 11. Desviación temporal del proyecto ................................................... 87

Figura 12. Diagrama de taxonomía herramienta .............................................. 94

Figura 13. Diagrama de taxonomía perfilado. .................................................. 94

Figura 14. Diagrama de taxonomía Participante .............................................. 95

Figura 15. Diagrama de taxonomía de más alto nivel. ..................................... 95

Figura 16. Relación Participante - Asignatura .................................................. 96

Figura 17. Relación Evento - Participante ........................................................ 96

Figura 18. Relación Evento - ToolElement ....................................................... 96

Figura 19. Relación Estudiante - ToolElement ................................................. 97

Figura 20. Relación Calificación - Estudiante ................................................... 97

Figura 21. Relación Calificación - EvaluativeToolElement ............................... 97

Figura 22. Relación Asignatura - Herramienta ................................................. 97

Figura 23. Relación ToolElement - Herramienta .............................................. 98

Figura 24. Relación ToolElement -TopicItem ................................................... 98

Figura 25. Relación Topic - TopicItem .............................................................. 98

Figura 26. Relación Perfil - ToolElement .......................................................... 98

Figura 27. Relación Participante - Perfil ........................................................... 99

Figura 28. Relación ToolElement – ToolElement ............................................. 99

Figura 29. Ejemplo relación isRelatedTo .......................................................... 99

Figura 30.Importación Protegé ....................................................................... 105

Figura 31. ObjectProperties Protege .............................................................. 106

Figura 32. Detalle propiedades Protegé ......................................................... 107

Figura 33. Atributos de concepto Protegé ...................................................... 108

Figura 34. Diagrama casos de uso OntoSakaiWS ......................................... 116

Figura 35. . Diagrama de clases OntoSakaiWS ............................................. 118

Figura 36. Diagrama de despliegue OntoSakaiWS ........................................ 124

Figura 37. . Diagrama de casos de uso OntoSakai Resources ...................... 132

Figura 38. Diagrama de clases OntoSakai Resources .................................. 134

Figura 39. Diagrama de componentes OntoSakai Resources........................ 135

Figura 40. Diseño Interface OntoSakai Resources: Login .............................. 136

Figura 41. Diseño Interface OntoSakai Resources: General .......................... 137

Figura 42. Diseño Interface OntoSakai Resources: Subida ........................... 137

Figura 43. Diseño Interface OntoSakai Resources: Topics Relacionados ..... 138

Figura 44. Diseño Interface OntoSakai Resources: Nuevo Topic .................. 138

Figura 45. Diseño Interface OntoSakai Resources: Nuevo TopicItem ........... 139

Figura 46. Diseño Interface OntoSakai Resources: Recursos relacionados .. 139

Figura 47. Diagrama de despliegue OntoSakai Resources ............................ 141

Figura 48. Diagrama de casos de uso OntoSakai Browser ............................ 149

Figura 49. Diagrama de clases OntoSakai Browser ...................................... 150

Figura 50. Diagrama de componentes OntoSakai Browser ........................... 151

Figura 51. Diseño Interface OntoSakai Browser: Login .................................. 152

Figura 52. Diseño Interface OntoSakai Browser: Listado de recursos ........... 153

Figura 53. Diseño Interface OntoSakai Browser: Recursos relacionados ...... 153

Figura 54. Diseño Interface OntoSakai Browser: Recursos relacionados

TopicItems ...................................................................................................... 154

Figura 55. Diseño Interface OntoSakai Browser: Recursos relacionados Topics

....................................................................................................................... 154

Figura 56. Diagrama de despliegue OntoBrowser .......................................... 156

Figura 57. Diagrama de despliegue de la solución ......................................... 159

Figura 58. Diagrama secuencia OntoSakaiWS: CU01 ................................... 209



















Figura 83. Diagrama secuencia OntoSakai Resources: CU01 ....................... 220





Figura 88. Diagrama secuencia OntoSakai Browser: CU01 ........................... 225






Figura 94. Comprobación Java ...................................................................... 231

Figura 95. Descarga Java .............................................................................. 232

Figura 96. Instalación JDK ............................................................................. 233

Figura 97. Acceso propiedades del sistema ................................................... 233

Figura 98. Propiedades del sistema ............................................................... 234

Figura 99. Propiedades avanzadas del sistema ............................................. 234

Figura 100. Nueva variable de entorno .......................................................... 235

Figura 101. Descarga SVN............................................................................. 236

Figura 102. Instalación SVN ........................................................................... 237

Figura 103. Descarga Maven ......................................................................... 238

Figura 104. Descarga Tomcat ........................................................................ 239

Figura 105. Catalina Properties ...................................................................... 240

Figura 106. Server Properties ........................................................................ 240

Figura 107. Descarga JDBC ........................................................................... 241

Figura 108. Instalación JDBC ......................................................................... 242

Figura 109. Descarga MySQL Server ............................................................ 243

Figura 110. Instalación MySQL Server ........................................................... 243

Figura 111. Acceso MySQL CommandLIne ................................................... 244

Figura 112. Creación de la base de datos ...................................................... 244

Figura 113. Descarga Sakai ........................................................................... 245

Figura 114. Descarga Sakai Completada ....................................................... 246

Figura 115. Ubicación Sakai.properties .......................................................... 246

Figura 116. Sakai.Properties .......................................................................... 247

Figura 117. Instalación Sakai ......................................................................... 247

Figura 118. Arranque servidor ........................................................................ 248

Figura 119. Pantalla Login Sakai .................................................................... 248

Figura 120. Apagado Servidor ........................................................................ 249

Figura 121. Copia OntoSakaiWS.war ............................................................. 249

Figura 122. Arranque servidor ........................................................................ 250

Figura 123. Listado de servicios OntoSakaiWS ............................................. 251

Figura 124. Copiado Herramientas ................................................................ 252

Figura 125. Instalación OntoSakai Browser ................................................... 252

Figura 126. Instalación OntoSakai Resources ............................................... 252

Figura 127. Resultado instalación herramienta .............................................. 253

Figura 128. Inicio Tomcat ............................................................................... 253

Figura 129. Creación nuevo sitio (A) .............................................................. 254

Figura 130. Creación nuevo sitio (B) .............................................................. 254

Figura 131. Creación nuevo sitio (C) .............................................................. 255

Figura 132. Creación nuevo sitio (D) .............................................................. 255

Figura 133. Creación nuevo sitio (E) .............................................................. 256

Figura 134. Creación nuevo sitio (FINAL) ...................................................... 256

Figura 135. Login OntoSakai Resources ........................................................ 257

Figura 136. Login OntoResources .................................................................. 259

Figura 137. Visión general OntoResources .................................................... 259

Figura 138. Subida de archivo ........................................................................ 260

Figura 139. Listado de topics ......................................................................... 260

Figura 140. Listado de recursos relacionados ................................................ 261

Figura 141. Subida completada ...................................................................... 261

Figura 142. Crear nuevo topic ........................................................................ 262

Figura 143. Crear nuevo TopicItem ................................................................ 263

Figura 144. Comprobación topic creado ........................................................ 264

Figura 145. Filtro de listados .......................................................................... 264

Figura 146. Login OntoBrowser ...................................................................... 265

Figura 147. Listado de recursos OntoBrowser ............................................... 265

Figura 148. Pestaña recursos relacionados ................................................... 266

Figura 149. Relaciones directas ..................................................................... 266

Figura 150. Relaciones a través de topicItem ................................................ 267

Figura 151. Relaciones a través de topic ....................................................... 267

Figura 152. Descarga de recurso ................................................................... 268

Figura 153. Tareas que componen Methontology .......................................... 272

Índice de tablas

Tabla 1. Sistemas LMS más usados ................................................................ 37

Tabla 2. Eventos generados por la herramienta Recursos .............................. 43

Tabla 3. Puntos de función OntoSakaiWS ....................................................... 72

Tabla 4. Factor de complejidad OntoSakaiWS ................................................. 73

Tabla 5. Calculo PF OntoSakaiWS .................................................................. 73

Tabla 6. Puntos de función OntoSakai Resources ........................................... 74

Tabla 7. Factor de complejidad OntoSakai Resources .................................... 75

Tabla 8. Calculo PF OntoSakai Resources ...................................................... 75

Tabla 9. Puntos de función OntoSakai Browser ............................................... 76

Tabla 10. Factor de complejidad OntoSakai Browser ...................................... 77

Tabla 11. Calculo PF OntoSakai Browser ........................................................ 77

Tabla 12. Calculo tiempo total desarrollo ......................................................... 78

Tabla 13. Detalle de las tareas ......................................................................... 80

Tabla 14. Coste económico material del proyecto. ........................................... 82

Tabla 15. Conste personal del proyecto ........................................................... 83

Tabla 16. Coste desglosado por tareas del proyecto ....................................... 83

Tabla 17. Coste total del proyecto .................................................................... 84

Tabla 18. Planificación de tareas real .............................................................. 86

Tabla 19. Glosario de términos ........................................................................ 93

Tabla 20. Diccionario de conceptos ............................................................... 101

Tabla 21. Relaciones Binarias ........................................................................ 102

Tabla 22. Atributos de instancia ..................................................................... 103

Tabla 23. Instancias ....................................................................................... 103

Tabla 24. Definición Actor 1 OntoSakaiWS .................................................... 115

Tabla 25. Definición actor 2 OntoSakaiWS .................................................... 115

Tabla 26. Casos de prueba OntoSakaiWS. .................................................... 122

Tabla 27. Pruebas de esfuerzo. ..................................................................... 123

Tabla 28. Definición actor OntoSakai Resources ........................................... 131

Tabla 29. Casos de prueba OntoSakai Resources ........................................ 141

Tabla 30. Definición actor 1 OntoSakai Browser ............................................ 148

Tabla 31. Casos de prueba OntoSakai Browser ............................................ 155

Tabla 32. Pruebas de integración ................................................................... 158

Tabla 33. Caso de uso OntoSakaiWS: CU01 ................................................. 173



















Tabla 52. Caso de uso OntoSakai Resources: CU01 .................................... 192










Tabla 62. Caso de uso OntoSakai Browser: CU01 ........................................ 202







Tabla 69. Roles de usuario............................................................................. 258

27

1. INTRODUCCIÓN

En este apartado ofrece una visión global sobre el proyecto que se

pretende desarrollar en este trabajo fin de grado. Abarca el proyecto

desde tres perspectivas, motivación, definición y objetivos que

pretendemos alcanzar como conclusión de este desarrollo.

1.1 Motivación

Los LMS (Learning Management System) se han consolidado, como

una herramienta flexible y dinámica para la enseñanza universitaria a

nivel mundial. Podemos definir LMS o Entorno Virtual de Aprendizaje

como una plataforma, que administra, distribuye y controla las actividades

de formación de una institución u organización. Define, por tanto, un

entorno de trabajo para apoyar la gestión de contenidos y los procesos

académicos, tanto para enseñanzas presenciales como a distancia.

De forma genérica, podríamos decir que las principales funciones de un

LMS moderno son las siguientes:

Gestionar recursos de usuarios así como materiales y actividades

de formación

Administrar el acceso, controlar y dar seguimiento del proceso de

aprendizaje

Realizar evaluaciones

Generar informes

Gestionar servicios de aprendizaje colaborativo como foros de

discusión, videoconferencias, entre otros

28

Figura 1. Estructura LMS [27]

La mayoría de los LMS comparten una estructura similar, ilustrada por

la figura 1, están basados en la Web, construidos con diversas

plataformas de desarrollo, como Java, Microsoft .NET o PHP. Por lo

general, emplean el uso de una base de datos como MySQL, Microsoft

SQL Server u Oracle como el almacén de datos de back-end. Aunque la

mayoría de los sistemas son desarrollados comercialmente y tienen

licencias de software comercial, hay varios sistemas que tienen una

licencia de código abierto.

El uso de LMS permite mejorar el proceso de enseñanza, así como

una mejor calidad y menor coste del proceso de aprendizaje. [24]

Atendiendo a lo expuesto anteriormente, podemos constatar que el uso

de LMS en los entornos educativos supone una serie de ventajas y

mejoras en el proceso formativo. Sin embargo, al margen de estas

ventajas, algunos estudios indican que aún existen retos que superar

antes de poder construir un entorno de enseñanza completo y exitoso.

Estos retos vienen dados principalmente por la falta de conocimiento

sobre la experiencia y las preferencias de la gran cantidad de estudiantes

y docentes que usan estos sistemas, los cuales, a nivel individual, tienen

diferentes habilidades, preferencias y formas de trabajar. [5]

De este modo, aunque los diferentes tipos de indicadores de uso están

disponibles en la mayoría de los LMS, la ausencia de herramientas para

29

interpretar automáticamente dicha información delega esta carga de

trabajo en los docentes, que deben buscar una posible correlación entre

los indicadores del uso y los resultados de los estudiantes de una manera

tediosa y artesanal.

Como resultado de los estudios citados anteriormente, dos aspectos

destacan como los más inmediatos y asequibles a la hora de mejorar un

LMS

En primer lugar, la personalización dentro de un LMS hace

referencia a la adaptación de los recursos y servicios de aprendizaje

de acuerdo con las necesidades reales del estudiante. Existen

diferentes alternativas (combinables entre sí) para conseguir esta

personalización: adaptación de contenido, centrado en búsquedas,

interfaces personalizadas (especialmente para personas con

necesidades especiales) e interfaces dependientes de dispositivos.

En segundo lugar, un LMS debe mostrar también un

comportamiento proactivo, es decir, debe ser capaz de

recomendar recursos y servicios tanto a los estudiantes –en su

proceso de aprendizaje- como a los docentes –en las decisiones

sobre la gestión del curso-. Como ejemplo, un LMS con

capacidades de recomendación podría ser muy útil cuando un

estudiante recibe malas calificaciones en una asignatura en

concreto. En este caso, el LMS podría ofrecer nuevas actividades

para ayudarle a detectar sus fallos y recomendarle nuevos

contenidos para reforzar sus conocimientos.

En definitiva, la motivación de este proyecto nace de la necesidad de

analizar y proponer herramientas y tecnologias para dotar de las

capacidades anteriormente mencionadas a un entorno LMS, con el

objetivo de convertirlo en un entorno, tanto para docencia como para

aprendizaje, más completo y capaz de adaptarse a las necesidades

específicas de cada tipo de usuario.

30

1.2 Definición

En el presente trabajo nos basamos en una de las principales

alternativas para llevar a cabo la personalización y recomendación de

servicios en un LMS, basada en el modelado de contexto mediante

ontologías. Las ontologías ofrecen descripciones formales y comunes de

los términos relacionados con un LMS. Estas descripciones pueden,

además, ser procesadas y compartidas por otras aplicaciones. Además,

permiten la extracción de conocimiento implícito derivado de la

clasificación y restricciones modeladas en la ontología. Con todo, las

ontologías son esenciales en un escenario donde la información

semántica debe tenerse en cuenta. A medida que el LMS registra un gran

volumen de datos y eventos generados por los usuarios, la semántica de

dichos datos y eventos podrían ser capturados y utilizados como entrada

en un sistema sensible al contexto integrado en cualquier LMS.

En este trabajo se sigue la línea de investigación basada en el

modelado a través de ontologías como una solución para ofrecer

personalización y recomendación en el contexto de un LMS. [28]

Completando el trabajo realizado en la investigación anteriormente

citada, lo primero que haremos será integrar las ontologías propuestas en

el artículo con una ontología de perfilado y una ontología de evaluación de

competencias [9]. Como resultado, se obtiene un modelo de conocimiento

llamado OntoSakai capaz de representar información semántica sobre los

componentes de un LMS, perfiles de los estudiantes y docentes y de los

resultados académicos. Sobre la base de este modelo, se definen varias

reglas de experto encaminadas a crear servicios de personalización y

recomendación. Como prueba de concepto, integramos nuestro sistema

sensible al contexto en Sakai, un sistema LMS conocido a nivel mundial y

que, actualmente, se está usando en UCAM.

En este trabajo, centraremos el esfuerzo en conseguir una integración

completa y funcional de OntoSakai con el ya mencionado, LMS utilizado

31

en la universidad, Sakai. De forma que desarrollaremos, como soporte

para posibilitar el acceso desde nuestro LMS a la ontología, una

aplicación de tipo servicio Web, que denominaremos OntoSakaiWS.

OntoSakaiWS, cuenta, tanto con funciones de lectura como de

escritura, así como una serie de métodos encargados de mantener la

integridad referencial y la coherencia dentro de la ontología.

Finalmente, con el objetivo de demostrar empíricamente que nuestro

desarrollo es realmente capaz de dotar de capacidades semánticas a un

LMS, se desarrollarán dos aplicaciones (tools en la terminología de

Sakai) capaces de gestionar recursos dentro el entorno LMS, con el valor

añadido de aportar información semántica a estos recursos.

Estas dos aplicaciones a desarrollar son:

OntoSakai Resources: Para la subida de archivos, similar a la

herramienta “Recursos” de Sakai pero con capacidades

semánticas.

OntoSakai Browser: Como aplicación de gestión de recursos y

recomendación de los mismos.

Cabe destacar que estas aplicaciones deben integrarse dentro del

entorno de Sakai, por lo que debemos desarrollarlas siguiendo su

arquitectura específica y tratando de que se integren lo mejor posible,

tanto con Sakai, como con nuestra ontología, OntoSakai.

32

1.3 Objetivos

Los objetivos generales y específicos que se pretenden conseguir

mediante la realización de este trabajo fin de grado son:

OG1. Integrar una serie de ontologías, previamente desarrolladas por

el departamento de Ingeniera Informática de UCAM, que conforman el

modelo ontológico OntoSakai.

OE1.1. Analizar las diferentes ontologías y establecer las bases

para la integración.

OE1.2. Establecer los nuevos elementos, relaciones y/o atributos

que debemos generar.

OE1.3. Implementar la integración de las ontologías que

componen OntoSakai mediante el lenguaje correspondiente.

OG2. Desarrollar un servicio Web fácilmente escalable y adaptable,

que actúe a modo de interface entre la ontología y el entorno LMS

permitiendo la comunicación e interoperabilidad entre ambos.

OG3. Desarrollar dos herramientas de gestión de recursos dentro del

LMS Sakai.

OE3.1. Herramienta para la subida de recursos al campus virtual

que permita adherir contenido semántico a los recursos subidos.

OE3.2. Herramienta para la visualización y descarga de los

recursos subidos. Esta herramienta debe incluir un servicio de

recomendación de recursos relacionados.

33

2. ESTADO DEL ARTE

2.1 Conceptos relevantes del dominio de la aplicación.

En este apartado vamos a tratar los aspectos más relevantes

relacionados con los desarrollos llevados a cabo en este trabajo. Hemos

organizado este apartado en dos grandes subapartados, de forma que

podamos tratar cada elemento de forma independiente, a fin de ofrecer

una visión completa y correcta de los hitos de este proyecto. Estas

secciones son: Sakai y OntoSakai.

2.1.1 Sakai.

En este apartado vamos a describir los aspectos de Sakai más

relevantes para el desarrollo de nuestro trabajo fin de grado.

Sakai es uno de los LMS más populares actualmente, usado por

diversas instituciones y universidades. Podemos definir Sakai como un

Entorno Virtual de Aprendizaje desarrollado inicialmente por las

universidades de Michigan e Indiana y puesto a disposición de la

comunidad como una plataforma de software libre. Actualmente, el

proyecto está gestionado por la Fundación Sakai, compuesta por más de

100 universidades de todo el mundo.

Sakai posee multitud de funcionalidades orientadas a mejorar la

experiencia educativa y facilitar la labor de los docentes.

Sakai conforma un sistema completo que está formado por diferentes

sitios (Equivalente a una asignatura) en los cuales los alumnos pueden

hacer uso de diferentes servicios (Herramientas puestas a disposición por

parte del equipo docente).

34

En nuestro caso, nos centraremos en la herramienta “Recursos” la cual

pretendemos mejorar, dotándola de información semántica.

La herramienta “Recursos” permite a los docentes subir archivos desde

su equipo al Campus Virtual. En el momento actual, cada recurso subido

pertenece a un sitio (Asignatura) concreto, y puede usarse únicamente en

el ámbito de ese sitio.

Los alumnos, por su parte, pueden hacer uso de esta herramienta para

visualizar los recursos contenidos en los sitios a los que tengan acceso y,

en caso de que así lo requieran, descargarlos.

Sin embargo, esta herramienta carece de las capacidades de

recomendación de recursos, por lo que su función se limita a ofrecer los

recursos subidos, sin más información respecto a ellos o respecto a las

áreas de conocimiento que tratan.

2.1.2 OntoSakai.

OntoSakai es la denominación que adopta el modelo ontológico que

pretendemos construir como núcleo del presente trabajo fin de grado.

Estará construido sobre la base de información de contexto de Sakai

(aplicable, con mínimas modificaciones a otros LMS) para lograr las

características de personalización y recomendación. El objetivo de este

modelo ontológico es representar y razonar sobre el proceso de

aprendizaje basado en la clasificación de todo el material educativo

disponible en el Campus Virtual (por ejemplo, recursos, tareas,

exámenes, foros de discusión, chats, etc.), teniendo en cuenta su

contenido, adecuación y uso, entre otros, y la generación de perfiles de

usuario (tanto para estudiantes como para docentes), teniendo en cuenta

los eventos generados por los mismos. Estos eventos son almacenados

automáticamente por Sakai dentro de la tabla Events de la base de datos.

35

En primer lugar, la clasificación del material ayudará a los estudiantes a

encontrar los recursos necesarios de manera más eficiente. Esta es la

base para lograr recomendaciones automatizadas tanto para estudiantes

como para docentes. En segundo lugar, el perfil de usuario también

permite a las recomendaciones en relación con el tipo de actividad que los

usuarios realizan en el LMS.

OntoSakai abarca varias áreas del proceso de aprendizaje al que da

soporte un LMS. La figura 2 muestra una representación esquemática de

las partes fundamentales de OntoSakai, resaltando los conceptos más

relevantes en cada área. El modelo se construirá sobre la base de varias

ontologías previamente desarrolladas por profesores del departamento. A

continuación se detallan y describen estas ontologías para su mejor

comprensión:

1. SakaiCoreOnt, representa las herramientas básicas ofrecidas por un

LMS y los elementos contenidos en las mismas, es decir, los recursos de

un curso específico, las discusiones del foro, los mensajes de chat, etc.

2. SakaiClassificationOnt, que se ocupa principalmente de la

clasificación semántica de todos los elementos en Sakai, a saber, todo el

material disponible de cada herramienta en cada curso.

3. OntoCompetence, que se ocupa de la evaluación de los alumnos,

teniendo en cuenta sus resultados de aprendizaje, calificaciones

obtenidas en las competencias que se espera que adquieran en cada

curso, etc. Esta ontología también define varios conceptos necesarios

para representar el proceso de aprendizaje, como participantes

(estudiantes o docentes) y asignaturas (cursos).

4. SakaiProfileOnt, que se ocupa de la representación de la

información de los perfiles de usuarios valiéndose para ello de los eventos

que producen dentro de Sakai.

36

Figura 2. Visión general de OntoSakai [28]

2.2 Relación con proyectos con la misma funcionalidad.

En este apartado del trabajo fin de grado, analizaremos los LMS más

relevantes, así como las principales iniciativas para integrar sistemas

expertos en los mismos y desarrollar técnicas de perfilado de usuarios

mediante ontologías. Como veremos a continuación, existe un incipiente

ámbito de trabajo en el área de la integración semántica dentro de los

LMS para proveerlos de sistemas expertos.

La encuesta del “Campus Computing Project” [33] datada en 2013

pone de manifiesto la continua transición del mercado de la educación

superior hacia los sistemas LMS. La encuesta aborda las herramientas

comerciales y de código abierto con mayor nivel de adopción en este

ámbito. Estas herramientas están resumidas en la tabla 1.

37

Sistemas de gestión de aprendizaje más usados

Software libre Comerciales

Blackboard/Angel/WEBCT (1997) Moodle (2002)

Desire2Learn (1999) Sakai (2004)

Pearson’s eCollege (2007) Canvas by instructure (2012)

Tabla 1. Sistemas LMS más usados

Estos sistemas cuentan con diferentes herramientas orientadas a la

recopilación de indicadores de uso y el rendimiento, siendo

responsabilidad de los profesores de su interpretación. Así, identificamos

la falta de estudios de posibles correlaciones entre los indicadores

específicos proporcionados por un LMS (por ejemplo, Sakai) y las

herramientas para ayudar a los profesores en los procesos de toma de

decisiones. También sería deseable aprovechar el conocimiento que, año

tras año, se genera de forma natural cuando se utiliza un LMS con el fin

de detectar proactivamente comportamientos y patrones que puedan

generar problemas académicos o de gestión.

En general, todos los LMS antes mencionados ofrecen varias

herramientas comunes para el establecimiento de estrategias para la

gestión de cursos [6]. Sin embargo, ninguno de ellos ofrece servicios de

personalización y/o recomendaciones a los docentes y estudiantes

basadas en el análisis de la clasificación de los contenidos disponibles así

como de los indicadores de uso.

Por otro lado, existe un incipiente ámbito de trabajo centrado en la

importancia de combinar la semántica con el conocimiento experto para

ofrecer servicios de recomendación en el LMS. Un reciente trabajo [16]

señala la conveniencia de utilizar las tecnologías orientadas a la web

semántica para mejorar el modelo de sistema de soporte para la toma

decisiones dentro de un LMS. Un excelente estudio se da en este trabajo

donde se han identificado varios estudios anteriores para extender las

características de un LMS a través de tecnologías de la web semántica

38

(por ejemplo, sistemas de tutoría o la búsqueda de materiales de

aprendizaje previamente etiquetados con información semántica).

Propone una arquitectura y un modelo de conocimiento para desarrollar

una herramienta inteligente para los servicios de recomendación en un

LMS, pero sin mostrar detalles acerca de la ontología, en la que todavía

están trabajando. Los autores también utilizan reglas como SWRL para

implementar servicios de recomendación. No se incluyen características

de personalización en este trabajo por el momento. Cabe destacar que,

gracias a las propiedades de las ontologías, en un hipotético futuro, sería

posible integrar OntoSakai con una ontología fruto de este trabajo.

Existen otros trabajos que tratan los sistemas expertos como base para

habilitar servicios de recomendación en LMS. Por ejemplo, en un reciente

trabajo [15], se presentan dos sistemas basados en reglas expertas cuyo

objetivo es recomendar cursos para estudiantes de pregrado. Una

plataforma de e-learning, basada en sistemas expertos, fue propuesta en

[32] para enseñar probabilidad en el ámbito de la escuela secundaria y

recomendar tareas de acuerdo con currículo turco para el curso de

matemáticas en escuela secundaria. Por último, existen otros trabajos

donde los problemas con el uso de sistemas de e-learning se mejoran

utilizando sistemas expertos, especialmente orientada a la solución de la

sobrecarga cognitiva y los problemas de desorientación [19] y los

comportamientos de resolución de dudas online de los docentes [20].

Cabe destacar que estas soluciones se enfocan a resolver problemas

concretos, mientras que OntoSakai propone una solución general y

personalizable. Además, estos trabajos no tienen en cuenta la información

semántica disponible dentro de un LMS, mientras que, para OntoSakai,

esta información es la base.

Por último, vale la pena mencionar otras interesantes propuestas de

sistemas de recomendación para LMS que no están basados en el uso de

sistemas expertos, como por ejemplo el uso de la Web 2.0 Entornos

Personales de Aprendizaje (PLE)[35], el uso de servicios Web [4], o

técnicas de minería de datos [30].

39

2.3 Estudio de viabilidad.

2.3.1 Alcance del proyecto.

Dada la gran complejidad y magnitud que puede llegar a alcanzar el

desarrollo de un sistema como el propuesto, se hace patente la necesidad

de definir un alcance que sea capaz de abarcar todos los objetivos

propuestos inicialmente así como de dar cabida a futuros desarrollos

dentro de esta misma línea de trabajo, al mismo tiempo que permita

acotar la realización del mismo al tiempo existente para la realización del

presente trabajo fin de grado.

Ha sido una ardua tarea delimitar el alcance del presente trabajo fin de

grado, debido, principalmente, a que el gran abanico de posibilidades

abierto en un primer momento, generaba una tendencia a realizar un

desarrollo completo de todas las soluciones posibles.

Dada la imposibilidad de tomar esta opción, por cuestiones meramente

temporales, se ha delimitado el presente proyecto al desarrollo de una

sólida base para la integración de OntoSakai con Sakai y la construcción

de una serie de aplicaciones que permiten la recomendación de recursos

a los usuarios del mismo.

Para una correcta definición del alcance de este proyecto se adjunta la

Figura 3, que muestra de forma visual, tanto el alcance del presente

proyecto como las potenciales vías futuras que se abren a raíz del mismo.

40

Figura 3. Alcance del proyecto

En la Figura 3, podemos ver, señalado por un recuadro verde, el

ámbito de desarrollo que abarca el presente proyecto. Como puede

observarse, los desarrollos a realizar van desde la integración de las

diferentes ontologías que componente OntoSakai, la creación de un

servicio Web que nos permita acceder a ellas desde el sistema de gestión

del aprendizaje, hasta el desarrollo de dos aplicaciones integradas dentro

del propio Sakai. Estas aplicaciones deben permitir trabajar dentro del

ámbito de recursos, tanto a docentes como a estudiantes, con recursos

clasificados con contenido semántico, permitiendo la recomendación de

los mismos.

El ámbito completo que representan las posibilidades que ofrece

OntoSakai pasa por la creación e integración de nuevas aplicaciones y

funcionalidades dentro de Sakai. Esta integración se basará en el trabajo

ya realizado en este trabajo fin de grado.

41

2.3.2 Estudio de la situación actual.

En esta sección vamos a analizar la situación actual del LMS Sakai,

trataremos de manera general todo su entorno.

Con el fin de garantizar las funciones más requeridas por los

estudiantes y docentes, Sakai proporciona un conjunto de herramientas

básicas que son adoptadas por la práctica totalidad de las entidades que

utilizan Sakai. Las herramientas básicas de Sakai pueden ser agrupadas

de la siguiente manera:

Herramientas comunicativas: Anuncios, Mensajes, Calendario,

Noticias, etc.

Herramientas colaborativas: Foro de Discusión, Wiki, chat, etc.

Herramientas de contenido: Recursos, Podcast, etc.

Herramientas de evaluación: tareas, test, etc.

Herramientas de monitoreo: Estadísticas, Mi área de trabajo,

etc.

Todas las herramientas disponibles no están incluidas en los sitios de

los cursos de forma predeterminada. Un subconjunto específico de

herramientas puede ser utilizado por los docentes con el fin de organizar,

supervisar y controlar los cursos en Sakai. Los docentes deben organizar

sus cursos y decidir que herramientas incluir dentro de los mismos. Estas

herramientas indican a los estudiantes qué tipo de contenido está

disponible para cada asignatura, cómo las tareas individuales deben

llevarse a cabo, o la proximidad de los plazos para las tareas y exámenes,

entre otros.

La figura 4 muestra las herramientas más usadas dentro del campus

virtual de la Universidad Católica de Murcia. La actividad dentro del LMS

ha sido estimada teniendo en cuenta el número de eventos de creación y

lectura para cada herramienta dentro del campus virtual.

42

Figura 4. Aplicaciones más usadas en UCAM [28]

Si atendemos a los datos arrojados por la Ilustración 8, podemos ver

que la herramienta más utilizada es “Resurces”, esta herramienta es la

encargada de gestionar los contenidos dentro del campus virtual,

permitiendo su subida y posterior visionado. Es por esto, que nos hemos

centrado en esta herramienta para el desarrollo de este proyecto, siendo

el objetivo del mismo, generar una herramienta con similares funciones

además de las relacionadas con los servicios de recomendación basados

en conocimiento experto.

A continuación vamos a analizar los mecanismos con los que cuenta

Sakai actualmente para poder valorar y analizar la actividad de los

usuarios dentro del entorno del campus virtual.

2.3.2.1 Registro y análisis de la actividad de usuario en Sakai.

El uso diario que los usuarios hacen del LMS queda registrado dentro

del mismo en forma de eventos, estos eventos son almacenados en la

base de datos de Sakai, de forma que cada evento realizado por un

usuario concreto en una herramienta determinada genera una nueva

ocurrencia en la tabla destinada a este fin.

43

Los principales tipos de eventos que Sakai almacena son los

siguientes:

Create/New: Se genera cuando se crea un nuevo elemento

dentro de una herramienta determinada.

Delete: Se genera cuando un elemento dentro de una

herramienta es eliminado.

Revise: Se genera cuando un elemento, que previamente

existía dentro de una herramienta, es modificado.

Read: Se genera cuando un elemento es accedido por un

usuario.

Response: Se genera cuando los usuarios participan en las

herramientas colaborativas.

Submit: Se genera cuando los estudiantes envían sus

respuestas a una tarea.

La tabla 2 nos muestra los tipos de eventos generados por la

herramienta “Recursos”, herramienta que pretendemos mejorar en este

trabajo fin de grado.

Herramienta Create/New Delete Revise Read Response Submit

Resources X X X X

Tabla 2. Eventos generados por la herramienta Recursos

En nuestro caso, capturaremos estos eventos en las nuevas

aplicaciones desarrolladas obteniendo un registro similar al conseguido

cuando se emplea la herramienta “Recursos” por defecto.

2.3.2.2 Conclusiones del estado actual.

Como ha quedado patente, las herramientas de Sakai están basadas

en la gestión manual por parte de los usuarios, evidenciando la ausencia

de un mecanismo que permita al docente establecer relaciones de

recomendación entre los recursos, ya sea por sus áreas de conocimiento

44

o bien por designación directa por parte de este, y al alumno recibir dichas

recomendaciones de forma sencilla y clara.

Se hace patente la acuciante necesidad de un mecanismo sencillo

mediante el cual podamos dotar al campus virtual de servicios de

recomendación mediante la integración en el mismo de una base de

conocimiento experto que pueda interactuar con las diferentes

herramientas.

2.3.3 Estudio y valoración de las alternativas de solución

En este apartado vamos a valorar las diferentes soluciones posibles

para el desarrollo de este trabajo fin de grado. De igual modo que hicimos

en secciones anteriores, vamos a dividir este apartado, de forma que

podamos tratar de forma independiente cada uno de los elementos a

desarrollar.

2.3.3.1 Integración de las diferentes ontologías que conforman OntoSakai.

La primera tarea a acometer para la realización de este trabajo fin de

grado será la de generar OntoSakai de forma que obtengamos un modelo

ontológico completo y funcional.

OntoSakai está compuesto a su vez por otras 4 ontologías

independientes. Para poder generar OntoSakai, es necesario unirlas,

modificando sus atributos, y establecer nuevas relaciones “Object

properties” entre los diferentes elementos de las mismas.

Para realizar esta tarea se valoraron diferentes alternativas que se

enumeran a continuación:

Realizar la edición de cada ontología añadiendo los nuevos

elementos de forma manual mediante un editor de texto.

45

Realizar la edición de las ontologías mediante una aplicación que

nos provea de interface gráfica, como podría ser Protegé.

Finalmente, y tras analizar las posibles opciones para esta etapa del

desarrollo, nos hemos decidido por usar Protegé, ya que consideramos

que nos ofrece las opciones de edición suficientes para nuestro objetivo,

amén de ser muy útil a la hora de eludir posibles fallos y errores que

podrían darse mediante la edición manual de las ontologías. Además,

Protegé nos ofrece un motor de consulta SPARQL que nos será de gran

utilidad a lo largo del desarrollo de nuestra aplicación, ya que SPARQL es

el lenguaje de consulta que emplearemos para interrogar el modelo

ontológico con el fin de obtener la información semántica necesaria para

el desarrollo de nuestra aplicación.

2.3.3.2 Integración de OntoSakai con Sakai.

Con respecto a la integración de nuestra nueva ontología con el LMS,

se ha decidido construir un servicio Web que actúe a modo de

intermediario entre ambos. Se ha tomado esta decisión debido a la

versatilidad que ofrece, creando un elemento totalmente independiente de

Sakai y que podría adaptarse, en un futuro, para su uso en aplicaciones

no necesariamente ligadas al LMS.

A este respecto, en el capítulo 4, apartados 4.1.2 y 4.2 de este trabajo

se detallan las herramientas y lenguajes de programación empleados.

2.3.3.3 Desarrollo de aplicaciones dentro de Sakai.

En este caso en particular, las alternativas a valorar no son

demasiadas, ya que, para desarrollar una herramienta que pueda ser

integrada en Sakai, debemos seguir una estricta guía de diseño

proporcionada por la propia comunidad de desarrollo. Si bien, partiendo

de estas premisas hemos podido tomar una serie de decisiones para

adecuar el desarrollo a nuestras necesidades.

46

A este respecto, hemos querido seguir la línea de desarrollo marcada

por los desarrollos propios de la universidad en el campus virtual de

UCAM y cuyos detalles analizaremos en la sección 4 de este documento.

47

48

3. METODOLOGIAS USADAS

En esta sección vamos a estudiar diferentes metodologías disponibles

para cada fase del desarrollo de este proyecto y analizaremos, en cada

caso, la metodología escogida destacando los motivos de esta elección.

La complejidad que supone el proceso de desarrollo de software y la

creciente necesidad de construir sistemas que cumplan con los requisitos

de los usuarios de forma completa y correcta ha llevado, a lo largo de los

años, al desarrollo de diversas metodologías de modelado. Estas

metodologías pretenden ser un modelo unificado en el cual los

desarrolladores puedan basarse a la hora de completar el proceso de

desarrollo de software.

Existen diversas metodologías que pueden ser adoptadas para los

desarrollos según las necesidades de cada caso en particular.

En nuestro caso, debido a la peculiaridad del desarrollo que vamos a

llevar a cabo, hemos dividido esta sección en varios apartados, a fin de

explicar cada caso con el mayor detalle posible.

3.1 Recogida de requisitos: IEEE 830.

Para que un proyecto de desarrollo de software pueda tener éxito es

crucial realizar una comprensión total de los requerimientos del software a

diseñar.

En la etapa del análisis y la especificación de requisitos, tanto el

cliente, como el desarrollador juegan un rol fundamental, debido a que el

primero se encarga de describir las necesidades que le apremian,

mientras que el segundo es el encargado de dar solución a dichas

necesidades. Debido a que la especificación es complicada de detallar,

desde el comienzo del desarrollo de los sistemas se ha tratado de realizar

49

una adecuada identificación de los requisitos del sistema derivados de las

necesidades de los usuarios.

En nuestro caso, para la realización del proceso de toma de requisitos

hemos optado por seguir el estándar IEEE 830. [1]

Mediante la adopción de este estándar se siguen una serie de

recomendaciones que garantizan una especificación de requisitos

correcta y completa.

Las principales ventajas que proporciona el uso de este estándar son:

El cliente puede describir claramente lo que desea.

El analista tiene una visión clara de las necesidades del cliente.

Establece las bases para el contrato de desarrollo

Reduce el esfuerzo de análisis, diseño y programación.

Sirve como referencia para validar o probar el software

desarrollado.

Según especifica este estándar, las principales características que

debe cumplir nuestro documento de especificación de requisitos (SRS)

son las siguientes:

Debe ser correcto.

No ambiguo.

Completo.

Verificable.

Consistente.

Clasificado.

Modificable.

Exportable.

Útil para las tareas de mantenimiento.

50

3.2 Modelado del sistema.

En este apartado vamos a analizar las metodologías que hemos

empleado para modelar cada uno de los elementos del sistema.

3.2.1 Modelado de OntoSakai.

Para el modelado final de la ontología, a pesar de que las ontologías

que conforman OntoSakai ya han sido diseñadas con anterioridad, es

importante resaltar la tarea de integración e implementación de dichas

ontologías que nos ocupa en este trabajo fin de grado también necesita

de un proceso metodológico. Para ello hemos utilizada la metodología

Methontology [41].

Esta metodología tiene sus raíces en las actividades identificadas por

el proceso de desarrollo de software propuesto por la organización IEEE.

Methontology proporciona guías sobre cómo llevar a cabo el desarrollo

de la ontología a través de las actividades de especificación,

conceptualización, formalización, implementación y mantenimiento. A

continuación se describe brevemente en qué consiste cada una de estas

actividades:

La actividad de especificación permite determinar por qué se

construye la ontología, cuál será su uso, y quiénes serán sus

usuarios finales.

La actividad de conceptualización se encarga de organizar y

convertir una percepción informal del dominio en una

especificación semi-formal, para lo cual utiliza un conjunto de

representaciones intermedias (RRII), basadas en notaciones

tabulares y gráficas, que pueden ser fácilmente comprendidas

por los expertos de dominio y los desarrolladores de ontologías.

51

El resultado de esta actividad es el modelo conceptual de la

ontología.

La actividad de formalización se encarga de la transformación

de dicho modelo conceptual en un modelo formal o semi-

computable.

La actividad de implementación construye modelos

computables en un lenguaje de ontologías (Ontolingua, RDF

Schema, OWL, etc.). La mayor parte de las herramientas de

ontologías permiten llevar a cabo esta actividad de manera

automática.

La actividad de mantenimiento se encarga de la actualización

y/o corrección de la ontología, en caso necesario.

En nuestro caso, debido a la particularidad de este desarrollo, hemos

realizado un diseño completo del modelo ontológico, partiendo de las

ontologías disponibles, centrándonos en las tareas de formalización e

integración.

Para evitar extendernos más en este apartado, el Anexo E contiene

una descripción más detallada de esta metodología.

3.2.2 Modelado de OntoSakaiWS y las herramientas a integrar dentro del campus.

En estos dos casos particulares, vamos a analizar varias posibilidades

planteadas para llevar a cabo el modelado de estas dos partes

fundamentales dentro del desarrollo de este trabajo fin de grado. Como

son, desarrollo en cascada [42], desarrollo en espiral [43] y desarrollo en

cascada con prototipado rápido [44]. Posteriormente indicaremos cuál de

ellas hemos escogido, analizando sus ventajas frente a la opción

descartada.

52

3.2.2.1 Modelo de desarrollo en cascada.

En Ingeniería de Software el desarrollo en cascada, también llamado

modelo en cascada, es el enfoque metodológico que ordena

rigurosamente las etapas del proceso para el desarrollo de software, de

tal forma que el inicio de cada etapa debe esperar a la finalización de la

etapa anterior.

Un enfoque clásico de una metodología de desarrollo en cascada sigue

los siguientes pasos:

1. Análisis de requisitos.

2. Diseño del Sistema.

3. Diseño del Programa.

4. Codificación.

5. Pruebas.

6. Implantación.

7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de

prueba conduce necesariamente al rediseño y nueva programación del

código afectado, aumentando los costos del desarrollo. La palabra

cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el

esfuerzo necesario para introducir un cambio en las fases más avanzadas

de un proyecto.

A continuación vamos a detallar las diferentes fases de este paradigma

de desarrollo adaptándolas a nuestro desarrollo en particular.

Análisis de requisitos: En nuestro caso, como hemos citado

anteriormente, la obtención y análisis de los requisitos de software se

hará mediante IEEE830. Detallado en el capítulo 3.1.

53

Diseño del sistema: En esta fase, se tomarán las decisiones

sobre la arquitectura a emplear y los diferentes subsistemas necesarios.

Diseño del programa: Se diseñan las diferentes soluciones que

integran nuestro sistema.

Codificación: Consiste en generar los componentes de software

anteriormente diseñados.

Pruebas: Se desarrollará un plan de pruebas que permita verificar

la completitud y corrección del software desarrollado.

Implantación: Se implantará el software en un entorno real para

comprobar su correcta integración y funcionamiento.

Mantenimiento: Resaltar que no es objetivo de este trabajo fin de

grado abarcar la fase de mantenimiento del sistema desarrollado.

En la Figura 5 podemos ver, de forma gráfica, las diferentes etapas de

esta metodología de desarrollo.

Figura 5. Desarrollo en cascada [7]

54

3.2.2.2 Modelo de desarrollo en espiral.

El desarrollo en espiral es un modelo de ciclo de vida del software

definido por primera vez por Barry Boehm en 1986, utilizado

generalmente en la Ingeniería de software. Las actividades de este

modelo se conforman en una espiral, en la que cada bucle o iteración

representa un conjunto de actividades. Las actividades no están fijadas a

ninguna prioridad, sino que las siguientes se eligen en función del análisis

de riesgo, comenzando por el bucle interior.

El modelo de desarrollo en espiral tiene en cuenta fuertemente el

riesgo que aparece a la hora de desarrollar software. Para ello, se

comienza mirando las posibles alternativas de desarrollo, se opta por la

de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente

quiere seguir haciendo mejoras en el software, se vuelve a evaluar las

distintas nuevas alternativas y riesgos y se realiza otra vuelta de la

espiral, así hasta que llegue un momento en el que el producto software

desarrollado sea aceptado y no necesite seguir mejorándose con otro

nuevo ciclo.

Básicamente consiste en una serie de ciclos que se repiten en forma

de espiral, comenzando desde el centro. Se suele interpretar como que

dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no

necesariamente debe ser así.

Al ser un modelo de desarrollo orientado a la gestión de riesgo se dice

que uno de los aspectos fundamentales de su éxito radica en que el

equipo que lo aplique tenga la necesaria experiencia y habilidad para

detectar y catalogar correctamente los riesgos.

En la Figura 6 podemos ver, de forma gráfica, los pasos que sigue el

modelo de desarrollo en espiral.

55

Figura 6. Modelo de desarrollo en espiral. [2]

3.2.2.3 Elección del modelo de desarrollo.

Finalmente, para el desarrollo tanto del servicio Web como de las

herramientas a integrar en Sakai, nos hemos decantado por el modelo de

desarrollo en cascada. La decisión se debe a que los requisitos han sido

fuertemente definidos desde el inicio del desarrollo y este modelo nos

permitirá estructurar el desarrollo de forma que obtengamos una serie de

hitos cerrados sin los cuales no nos sería posible continuar con el

desarrollo.

Asumir este modelo de desarrollo, sin embargo, conlleva una serie de

riesgos que debemos asumir. El más importante de ellos tiene que ver

con que los errores de análisis y diseño son difíciles de eliminar, y se

propagan a las etapas siguientes con un efecto conocido como “bola de

nieve”.

Para evitar este efecto vamos a adoptar una variante del modelo de

desarrollo en cascada, conocida como Modelo en cascada con

prototipado rápido.

56

El modelo en cascada con prototipado rápido consiste en construir,

durante la fase de análisis, un prototipo rápido, que ayudará a refinar y

validar la especificación de requisitos.

Después, este prototipo se desecha y el desarrollo prosigue en

cascada, con mayor seguridad de que los requisitos se han especificado

correctamente. En la figura 7, podemos observar el ciclo que sigue este

modelo de desarrollo.

Figura 7. Modelo de desarrollo en cascada con prototipado rápido. [39]

57

4. TECNOLOGIAS Y HERRAMIENTAS USADAS EN EL

PROYECTO

Para el desarrollo llevado a cabo en este TFG se han empleado una

serie de tecnologías y herramientas que se enumeran, detallan y explican

en el presente capitulo.

4.1 Tecnologías empleadas.

En este apartado vamos a definir los diferentes lenguajes de

programación, modelos de datos, protocolos y frameworks que hemos

necesitado en el desarrollo del presente trabajo fin de grado.

4.1.1 Desarrollo de la ontología.

4.1.1.1 RDF.

El modelo de datos RDF [23] es similar a los enfoques de modelado

conceptual clásicos como entidad-relación o diagramas de clases, ya que

se basa en la idea de hacer declaraciones sobre los recursos (en

particular, recursos web) en forma de expresiones sujeto-predicado-

objeto. Estas expresiones son conocidos como triples en terminología

RDF. El sujeto indica el recurso y el predicado denota rasgos o aspectos

del recurso y expresa una relación entre el sujeto y el objeto. Por ejemplo,

una forma de representar la idea de "El cielo tiene el color azul" en RDF

es como el triple de un objeto que denota "el cielo", un predicado que

denota "tiene el color" y un objeto que denota "azul". Por lo tanto RDF

cambia objeto por sujeto que se utilizaría en la notación clásica de un

modelo entidad-atributo-valor en diseño orientado a objetos, objeto (el

cielo), atributo (color) y el valor (azul). RDF es un modelo abstracto con

varios formatos de serialización (es decir, los formatos de archivo), por lo

que la forma particular en que se codifica un recurso o triple varía de un

formato a otro.

58

Este mecanismo para describir recursos es un importante componente

de la actividad de la Web Semántica de W3C: una etapa evolutiva de la

World Wide Web en la que el software automatizado puede almacenar,

intercambiar y utilizar información legible por máquina distribuida a través

de la Web, lo que a su vez, permite a los usuarios manejar la información

con mayor eficiencia y seguridad. El modelo de datos simple de RDF y la

capacidad de modelar diferentes, conceptos abstractos, también ha

llevado a su uso creciente en la gestión del aplicaciones del conocimiento

no relacionadas con la actividad en la Web Semántica.

4.1.1.2 OWL.

OWL (W3C Web Ontology Language) [26] es un lenguaje web

semántico diseñado para representar conocimiento rico y complejo sobre

elementos, grupos de elementos y las relaciones entre ellos. OWL es un

lenguaje basado en lógica computacional, por tanto, el conocimiento

expresado en OWL puede ser explotado por aplicaciones.

OWL está basado en gran medida en RDF, no en vano, está construido

sobre las bases de este, sin embargo, OWL presenta un avance

significativo respecto a RDF. Esto es debido a que define una serie de

operadores que aportan complejidad permitiendo una expresividad mucho

más amplia. Estos operadores hacen referencia, en gran parte, al modo

en el que debemos escribir los conceptos. De forma que deben estar

claramente separadas las propiedades de objetos de las de datos. Algo

que no estaba presente en RDF.

En síntesis, podríamos decir que RDF especifica que elementos

debemos definir para describir un modelo ontológico, mientras que es

OWL el que nos indica cómo debemos definirlos mediante una serie de

reglas y operadores.

59

4.1.1.3 SPARQL.

SPARQL [34] es un lenguaje estandarizado para la consulta de grafos

RDF, normalizados por el RDF Data Access Working Group (DAWG) del

World Wide Web Consortium (W3C). Es una tecnología clave en el

desarrollo de la Web Semántica que se constituyó como Recomendación

oficial del W3C el 15 de enero de 2008.

Al igual que sucede con SQL, es necesario distinguir entre el lenguaje

de consulta y el motor para el almacenamiento y recuperación de los

datos. Por este motivo, existen múltiples implementaciones de SPARQL,

generalmente ligados a entornos de desarrollo y plataformas tecnológicas.

En un principio SPARQL únicamente incorporaba funciones para la

recuperación sentencias RDF. Sin embargo, algunas propuestas también

incluyen operaciones para el mantenimiento (creación, modificación y

borrado) de datos.

4.1.2 Desarrollo de OntoSakaiWS.

4.1.2.1 Apache Jena.

Apache Jena [3] es un framework Java para construir aplicaciones

basadas en ontologías.

Jena se desarrolló en HP Labs en el 2000, en 2009 HP cedió el

proyecto a la fundación Apache que decidió adoptarlo en noviembre de

2010.

Su arquitectura incluye:

API para trabajar (leer, procesar, escribir) ontologías RDF y

OWL.

Motor de inferencia para razonar sobre ontologías RDF y OWL.

60

Estrategias de almacenamiento flexible para almacenar tripletas

RDF en memoria o fichero.

Motor de consulta compatible con especificación SPARQL.

4.1.2.2 Java EE.

Java Platform, Enterprise Edition o Java EE [31] es una plataforma de

programación para desarrollar y ejecutar software de aplicaciones en el

lenguaje de programación Java. Permite utilizar arquitecturas de N capas

distribuidas y se apoya ampliamente en componentes de software

modulares ejecutándose sobre un servidor de aplicaciones. La plataforma

Java EE está definida por una especificación. Java EE es también

considerada informalmente como un estándar debido a que los

proveedores deben cumplir ciertos requisitos de conformidad para

declarar que sus productos son conformes a Java EE; estandarizado por

The Java Community Process / JCP.

4.1.2.3 Apache Axis.

Apache Axis [12] es un framework de código abierto, basado en XML

para servicios web. Consiste en una implementación en Java y otra en

C++ del servidor SOAP, así como diversos utilitarios y APIs para generar

y desplegar aplicaciones de servicios web. Por medio de Apache Axis, los

desarrolladores pueden crear aplicaciones computacionales

interoperables y distribuidas. Axis se desarrolla bajo los auspicios de la

Apache Software Foundation.

4.1.2.4 SOAP.

SOAP [8] es un protocolo estándar que define cómo dos objetos en

diferentes procesos pueden comunicarse por medio de intercambio de

datos XML. Este protocolo deriva de un protocolo creado por Dave Winer

en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros.

61

Está actualmente bajo el auspicio de la W3C. Es uno de los protocolos

utilizados en los servicios Web.

Básicamente SOAP Es un paradigma de mensajería de una dirección

sin estado, que puede ser utilizado para formar protocolos más complejos

y completos según las necesidades de las aplicaciones que lo

implementan. Puede formar y construir la capa base de una "pila de

protocolos de servicio Web", ofreciendo un framework de mensajería

básica en el cual los servicios Web se pueden construir.

La arquitectura SOAP está formada por varias capas de especificación:

MEP (Message Exchange Patterns) para el formato del mensaje, enlaces

subyacentes del protocolo de transporte, el modelo de procesamiento de

mensajes, y la capa de extensibilidad del protocolo. SOAP es el sucesor

de XML-RPC, a pesar de que toma el transporte y la neutralidad de la

interacción, así como el envelope / header / body, de otros modelos

(probablemente de WDDX).

4.1.2.5 Servicio Web.

Para garantizar la interoperabilidad entre el entorno LMS y nuestro

modelo ontológico, OntoSakai, se pretende desarrollar un servicio Web

que actué de interface entre ambos. En esta sección trataremos de

explicar los conceptos más relevantes para el desarrollo de nuestra

interface.

Un servicio Web [40] es una tecnología que utiliza un conjunto de

protocolos y estándares que sirven para intercambiar datos entre

aplicaciones. Distintas aplicaciones de software desarrolladas en

lenguajes de programación diferentes, y ejecutadas sobre cualquier

plataforma, pueden utilizar los servicios web para intercambiar datos en

redes de ordenadores como Internet. La interoperabilidad se consigue

mediante la adopción de estándares abiertos. Las organizaciones OASIS

y W3C son los comités responsables de la arquitectura y reglamentación

62

de los servicios Web. Para mejorar la interoperabilidad entre distintas

implementaciones de servicios Web se ha creado el organismo WS-I,

encargado de desarrollar diversos perfiles para definir de manera más

exhaustiva estos estándares. Es una máquina que atiende las peticiones

de los clientes web y les envía los recursos solicitados.

4.1.3 Desarrollo de las herramientas integradas con Sakai.

4.1.3.1 Maquetación del frontend.

Para la maquetación de las nuevas herramientas de recursos (Sakai

Tools) hemos usado HTML5 y CSS3.

HTML5

HTML5 [19] es la quinta revisión importante del lenguaje básico de la

World Wide Web, HTML. HTML5 especifica dos variantes de sintaxis para

HTML: un «clásico» HTML (text/html), la variante conocida como HTML5 y

una variante XHTML conocida como sintaxis XHTML5 que deberá ser

servida como XML. Esta es la primera vez que HTML y XHTML se han

desarrollado en paralelo.

La versión definitiva de la quinta revisión del estándar se publicó en

octubre de 2014.

CSS3.

CSS [25] es un lenguaje usado para definir y crear la presentación de

un documento estructurado escrito en HTML o XML (y por extensión en

XHTML). El World Wide Web Consortium (W3C) es el encargado de

formular la especificación de las hojas de estilo que servirán de estándar

para los agentes de usuario o navegadores.

63

4.1.3.2 Desarrollo del backend.

En este apartado, vamos a detallar las tecnologias que hemos utilizado

para gestionar la lógica de negocio de nuestra aplicación, comprendiendo

tratamiento de información aportada por el usuario, acceso a bases de

datos, etc.

Java EE.

Esta tecnología ya ha sido detallada en la sección 4.1.2.2.

Java Server Pages (JSP).

JavaServer Pages (JSP) [11] es una tecnología que ayuda a los

desarrolladores de software a crear páginas web dinámicas basadas en

HTML, XML, entre otros tipos de documentos. JSP es similar a PHP, pero

usa el lenguaje de programación Java.

Spring Framework.

Spring [21] es un framework para el desarrollo de aplicaciones y

contenedor de inversión de control, de código abierto para la plataforma

Java.

Si bien las características fundamentales de Spring Framework pueden

ser usadas en cualquier aplicación desarrollada en Java, existen variadas

extensiones para la construcción de aplicaciones web sobre la plataforma

Java EE. A pesar de que no impone ningún modelo de programación en

particular, este framework se ha vuelto popular en la comunidad al ser

considerado una alternativa, sustituto, e incluso un complemento al

modelo EJB (Enterprise JavaBean).

En concreto, nosotros hacemos uso del framework de acceso remoto,

para exportación de objetos creados dentro del servlet hacia la página

JSP principal.

64

Javascript y jQuery.

Utilizamos jQuery [22] para gestionar la lógica de negocio desde el lado

del cliente.

jQuery es una biblioteca de JavaScript [37] que permite simplificar la

manera de interactuar con los documentos HTML, manipular el árbol

DOM, manejar eventos, desarrollar animaciones y agregar interacción con

la técnica AJAX a páginas web.

JQuery ofrece una serie de funcionalidades basadas en JavaScript que

de otra manera requerirían de mucho más código, es decir, con las

funciones propias de esta biblioteca se logran grandes resultados en

menos tiempo y espacio.

MySQL.

Hemos utilizado MySQL como base sobre la que montar la base de

datos de Sakai.

MySQL [29] es un sistema de gestión de bases de datos relacional,

multihilo y multiusuario.

4.2 Herramientas empleadas.

4.2.1 Protegé.

Hemos utilizado Protegé [17] para todo lo relacionado con el

tratamiento de las Ontologías. Protegé es una aplicación de software libre,

creada y soportada por la universidad de Stanford que nos proporciona un

editor de ontologías y un potente framework con el que trabajar sobre las

mismas.

Mediante esta alternativa contamos con un entorno gráfico y una serie

de asistentes que nos ayudarán en la tarea de unificar OntoSakai.

65

Cabe destacar, que ya estamos familiarizados con este framework ya

que fue el empleado en la asignatura Ingeniería del Conocimiento para el

desarrollo de la misma. Si, bien, el uso que deberemos darle dentro del

marco de este desarrollo se escapa, en algunos aspectos, a lo visto en la

asignatura.

4.2.2 Eclipse.

Hemos usado este conocido IDE tanto para el desarrollo de

OntoSakaiWS como para el desarrollo de las herramientas de Sakai.

Eclipse [10] es un programa informático compuesto por un conjunto de

herramientas de programación de código abierto multiplataforma para

desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido",

opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta

plataforma, típicamente ha sido usada para desarrollar entornos de

desarrollo integrados (del inglés IDE), como el IDE de Java llamado Java

Development Toolkit (JDT) y el compilador (ECJ) que se entrega como

parte de Eclipse (y que son usados también para desarrollar el mismo

Eclipse).

4.2.3 Apache Maven.

Hemos utilizado Maven [13] para diferentes tareas dentro del desarrollo

de este trabajo fin de grado.

Construcción y publicación del LMS Sakai.

Generación del arquetipo sobre el cual hemos desarrollado las

diferentes tools para Sakai.

Construir y publicar las herramientas desarrolladas para Sakai.

Maven es una herramienta de software para la gestión y construcción

de proyectos Java.

66

Maven utiliza un Project Object Model (POM) para describir el proyecto

de software a construir, sus dependencias de otros módulos y

componentes externos, y el orden de construcción de los elementos.

Viene con objetivos predefinidos para realizar ciertas tareas claramente

definidas, como la compilación del código y su empaquetado.

4.2.4 Apache Tomcat.

Hemos utilizado Tomcat [14] como servidor de aplicaciones sobre el

que hemos publicado tanto Sakai, junto con las nuevas herramientas

desarrolladas, como nuestro servicio web. También se encuentran

publicadas dentro de este servidor, las ontologías que conforman

OntoSakai.

Apache Tomcat funciona como un contenedor de servlets desarrollado

bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat

implementa las especificaciones de los servlets y de JavaServer Pages

(JSP) de Oracle Corporation.

4.2.5 Sublime Text.

Hemos utilizado Sublime Text [38] como editor de texto enriquecido

para desarrollar las funcionalidades JavaScript/jQuery.

Sublime Text es un editor de texto y editor de código fuente está escrito

en C++ y Python para los plugins. Desarrollado originalmente como una

extensión de Vim, con el tiempo fue creando una identidad propia, por

esto aún conserva un modo de edición tipo vi llamado Vintage mode.

Se distribuye de forma gratuita, sin embargo no es software libre o de

código abierto, se puede obtener una licencia para su uso ilimitado, pero

él no disponer de ésta no genera ninguna limitación más allá de una alerta

cada cierto tiempo.

67

4.2.6 DBVisualizer.

Hemos utilizado DBVisualizer [36] como aplicación principal para

trabajar con la base de datos de Sakai.

DbVisualizer es una herramienta de base de datos multiplataforma que

soporta la mayoría de bases de datos relacionales. Permite realizar

múltiples conexiones simultáneas a distintas bases de datos a través de

drivers jdbc y, con ello, navegar por la estructura de la base de datos, ver

características de los objetos de la misma, editar las tablas de una

manera gráfica, ejecutar sentencias y scripts SQL, realizar reingeniería

inversa para mostrar, en base a las claves definidas, la relación entre las

tablas de una manera gráfica, etc.

68

69

5. ESTIMACIÓN DE RECURSOS Y PLANIFICACIÓN

En esta sección vamos a realizar la planificación del proyecto, tanto

desde el punto de vista temporal como desde una perspectiva de

asignación de recursos (humanos y técnicos) con el fin de cumplir con los

objetivos marcados en cada una de las fases del proyecto.

La gestión de todo proyecto software siempre comienza con la

planificación del proyecto y sus actividades. Antes de comenzar el

proyecto se debe hacer una estimación de todos los factores que

conducirán a culminar el proyecto de una forma satisfactoria.

Es muy importante realizar una correcta planificación del proyecto,

determinando tareas y tiempos que deben cumplirse, así como asociar

responsables a cada una de ellas para asegurar el correcto cumplimiento.

Una correcta estimación del proyecto debería cumplir casi con

exactitud el verdadero coste y esfuerzo que al final tendrá el desarrollo del

proyecto. Si bien es cierto que, raramente, se suele acertar plenamente

con la planificación de un proyecto de software, por lo que no suele darse

una correlación exacta entre la planificación y el desarrollo real del

proyecto. Realizar una buena estimación, tanto temporal como de costes,

requiere un alto grado de experiencia en el desarrollo de proyectos de

software, con el que nosotros, en el momento actual, no contamos.

5.1 Fases del proyecto.

El proyecto se inició el día 1 de febrero de 2014. El desarrollo del

mismo ha sido dividido en diferentes fases que se detallan a continuación:

Estudio previo: Esta primera fase incluye el estudio de la

plataforma Sakai, basándonos en la documentación aportada por la

propia comunidad, inscribiéndonos y participando activamente en

70

las diferentes listas de correo que soportan a la comunidad Sakai y

manteniendo reuniones con el experto en Sakai dentro del entorno

de la Universidad Católica de Murcia. En esta fase también hemos

realizado un estudio sobre las diferentes tecnologías a utilizar.

Análisis y diseño: El análisis llevado a cabo en esta fase

comprende la especificación de requisitos, la decisión de las

herramientas a usar, casos de uso y diagramas de secuencia. Por

otro lado, con respecto al diseño, se han realizado prototipos, para

ver el aspecto visual de la GUI del sistema. Finalmente, se ha

creado un diagrama de clases, y se ha diseñado un diagrama de

despliegue de la herramienta.

Preparación del entorno de desarrollo: En la fase de preparación

del entorno se ha realizado un estudio de los diferentes entornos de

desarrollo posibles siendo finalmente el elegido Eclipse sobre una

versión de Windows 7 virtualizada con VMware. Dentro de este

sistema virtualizado hemos optado por Tomcat como servidor de

aplicaciones y MySQL como entorno para la base de datos de

Sakai.

Implementación y desarrollo: En el transcurso de la fase de

implementación y desarrollo hemos llevado al cabo la instalación de

la plataforma Sakai, la integración de las diferentes ontologías que

componen OntoSakai, el desarrollo del servicio web que da soporte

a la misma y el desarrollo de las diferentes herramientas que

integraremos en Sakai, tal y como se describe en el análisis y

diseño del proyecto.

Pruebas: Este periodo comprende el desarrollo del plan de

pruebas, para ello se verifican los requerimientos detallados en la

fase de análisis y diseño. Finalmente, para comprobar el

funcionamiento del sistema, se ejecutarán diversas pruebas para

71

comprobar la robustez y correcto funcionamiento de todo el

desarrollo.

Puesta en marcha: En esta última fase, se simula una integración

real del sistema desde cero, se genera, al mismo tiempo, un manual

de instalación con el objetivo de facilitar la implementación de

nuestra solución a los futuros usuarios.

5.2 Estimaciones utilizadas.

En esta sección analizaremos los costes y dimensiones del proyecto

utilizando la técnica de estimación por puntos de función.

5.2.1 Estimación por puntos de función

Este método de estimación contempla la aplicación a desarrollar como

una caja negra, es decir, no interesan las peculiaridades de la aplicación,

sino que se centra en lo que puede ver el usuario. El objetivo es evaluar

una aplicación informática en base a sus características externas.

Estas características se descomponen en dos grandes grupos:

La funcionalidad que provee el sistema: Hace

referencia a aquellos elementos que dan soporte a los

formularios de entrada, salida, consultas y ficheros a los

que debe dar soporte la aplicación.

Los factores de complejidad: Hace referencia a los

diferentes indicadores del entorno en que se ha de

desarrollar y explotar la aplicación informática.

Para una mejor comprensión hemos decidido realizar la estimación de

cada parte del desarrollo por separado.

72

5.2.1.1 OntoSakaiWS

Hemos incluido en este cálculo, por simplicidad y, porque realmente

son dos elementos que van de la mano, la integración de OntoSakai.

Como se ve en la tabla 3, se ha realizado el cálculo de los puntos de

función sin ajustar para el servicio web que dará soporte a OntoSakai.

Tipo elemento

Dificultad Peso Cantidad Total Total Elemento

Entradas

Simple 3 1 3 17

Media 4 1 4

Compleja 5 2 10

Total Entradas

Salidas

Simple 4 0 0 0

Media 5 0 0

Compleja 7 0 0

Total Salidas

Ficheros Internos

Simple 3 1 3 17

Media 4 2 8

Compleja 6 1 6

Total Ficheros Internos

Ficheros Externos

Simple 5 0 0 28

Media 7 4 28

Compleja 10 0 0

Total Ficheros externos

Consultas externas

Simple 5 3 15 39

Media 7 2 14

Compleja 10 1 10

Total Consultas externas

Total puntos de función sin ajustar (PFSA) 101 Tabla 3. Puntos de función OntoSakaiWS

73

El próximo paso es ajustar los anteriores valores en base a las

descripciones de la tabla 4:

# Factor de complejidad Peso Valor Factor

1 Sistema distribuido 2 1 2

2 Tiempo de respuesta 2 1 1

3 Eficiencia por el usuario 1 3 3

4 Proceso interno complejo 1 3 3

5 Reusabilidad 1 2 2

6 Facilidad de instalación 0.5 2 1

7 Facilidad de uso 0.5 1 0.5

8 Portabilidad 2 5 10

9 Facilidad de cambio 1 5 5

10 Concurrencia 1 5 5

11 Seguridad 1 1 1

12 Acceso directo por terceras partes

1 2 2

13 Facilidades especiales de entrenamiento a usuarios finales

1 1 1

Factor de complejidad 36.5 Tabla 4. Factor de complejidad OntoSakaiWS

En este momento se puede obtener el valor corregido de los puntos de

función, cuya fórmula viene definida por:

PF=PFSA*ACT

Sustituyendo los valores calculados hasta el momento en la anterior

formula se obtiene:

ACT 0,65 + 0,01 * Ʃ Fi (i=1…14)

ACT 0,65+0,01*36,5=1,015

PF 101*1.015=102,5

Tabla 5. Calculo PF OntoSakaiWS

Como puede verse en la tabla 5, considerando un punto de función por día se necesitarían un total de 102 días.

74

5.2.1.2 OntoSakai Resources.

En la tabla 6 se ha realizado el cálculo de los puntos de función sin

ajustar para la herramienta de subida de recursos.

Tipo elemento Dificultad Peso Cantidad Total Total Elemento

Entradas

Simple 3 1 3 17

Media 4 1 4

Compleja 5 1 10

Total Entradas

Salidas

Simple 4 3 12 12

Media 5 0 0

Compleja 7 0 0

Total Salidas

Ficheros Internos

Simple 3 2 6 14

Media 4 2 8

Compleja 6 0 0


Ficheros Externos

Simple 5 0 0 0

Media 7 0 0

Compleja 10 0 0


Consultas externas

Simple 5 2 10 17

Media 7 1 7

Compleja 10 0 0


Total puntos de función sin ajustar (PFSA) 60 Tabla 6. Puntos de función OntoSakai Resources

75









6 Facilidad de instalación 0.5 1 0.5





11 Seguridad 1 2 2

12 Acceso directo por terceras partes

1 2 2


1 1 1

Factor de complejidad 25 Tabla 7. Factor de complejidad OntoSakai Resources



PF=PFSA*ACT


formula se obtiene:

ACT 0,65 + 0,01 * Ʃ Fi (i=1…14)

ACT 0,65+0,01*25=0,9

PF 60*0,9=54

Tabla 8. Calculo PF OntoSakai Resources

Como puede verse en la tabla 8, considerando un punto de función por día se necesitarían un total de 54 días.

76

5.2.1.3 OntoSakai Browser

En la tabla 9 se ha realizado el cálculo de los puntos de función sin

ajustar para la herramienta de subida de recursos.

Tipo elemento Dificultad Peso Cantidad Total Total Elemento

Entradas

Simple 3 1 3 3

Media 4 0 0

Compleja 5 0 0

Total Entradas

Salidas

Simple 4 2 8 8

Media 5 0 0

Compleja 7 0 0

Total Salidas

Ficheros Internos

Simple 3 1 3 21

Media 4 3 12

Compleja 6 1 6


Ficheros Externos

Simple 5 0 0 0

Media 7 0 0

Compleja 10 0 0


Consultas externas

Simple 5 4 20 27

Media 7 1 7

Compleja 10 0 0


Total puntos de función sin ajustar (PFSA) 59 Tabla 9. Puntos de función OntoSakai Browser

77









6 Facilidad de instalación 0.5 1 0.5





11 Seguridad 1 2 2

12 Acceso directo por terceras partes 1 2 2


1 1 1

Factor de complejidad 20 Tabla 10. Factor de complejidad OntoSakai Browser



PF=PFSA*ACT


formula se obtiene:

ACT 0,65 + 0,01 * Ʃ Fi (i=1…14)

ACT 0,65+0,01*20=0,85

PF 59*0,85=50,15

Tabla 11. Calculo PF OntoSakai Browser

Como puede verse en la tabla 11, considerando un punto de función

por día se necesitarían un total de 50 días.

78

5.2.1.4 Tiempo total de desarrollo

Atendiendo a los cálculos anteriores obtenemos el resultado reflejado

en la tabla 12.

Desarrollo Tiempo

OntoSakaiWS 102

OntoSakai Resources 54

OntoSakai Browser 50

Total: 206 días.

Tabla 12. Calculo tiempo total desarrollo

Por tanto, obtenemos como resultado que este desarrollo ocupará un

total de 206 días.

5.3 Planificación temporal del proyecto

En este apartado se recoge la planificación del proyecto, definiendo las

tareas y la programación mediante la realización de un diagrama de

Gantt.

La Figura 8 muestra el diagrama de Gantt completo.

79

Figura 8. Diagrama de Gantt General

.

Como puede verse en la figura 8, el proyecto comienza el día 1 de

febrero de 2014 y finalizaría, según nuestra planificación, el día 26 de

agosto de ese mismo año. Cumpliéndose así, de forma exacta, los 206

días que habíamos planificado anteriormente.

80

Tabla 13. Detalle de las tareas

Como puede verse tanto en el diagrama de Gantt como en la tabla 13,

apenas ha existido solapamiento en las tareas, si bien, en la fase de

estudio previo y en la de preparación del entorno de desarrollo existe un

mínimo solapamiento.

En cambio, en la última fase, puesta en marcha, ambas tareas se

solapan, ya que se han llevado a cabo de forma simultánea.

81

Como puede verse la fase de estudio previo ocupa una gran parte del

tiempo de desarrollo del proyecto. Esto es debido a que partíamos con

unos conocimientos de basé bastante básicos y a las dificultades que

hemos encontrado a la hora de documentarnos sobre Sakai. Debido a su

farragosa plataforma con información obsoleta e incompleta.

De igual modo, la fase de implementación ocupa también un gran

porcentaje del tiempo empleado. Esta fase ha sido primordial en el

desarrollo del proyecto, nos hemos encontrado con las dificultades

propias de enfrentarnos por primera vez a nuevos entornos de desarrollo

con los que no habíamos trabajo hasta el momento.

5.4 Coste económico

En este apartado, vamos a detallar el coste derivado del desarrollo de

este proyecto.

Los costes derivados de un proyecto se pueden dividir en dos grandes

grupos, costes materiales y costes humanos.

5.4.1 Costes materiales

En la tabla 14 detallamos el coste de los equipos informáticos y el

software que hemos necesitado para el desarrollo de este trabajo fin de

grado.

82

Concepto Coste

Equipo MacBook Pro 15’ Late 2012 970€

Licencia S.O. Windows 7 Ultimate 230€

Licencia DBVisualizer Pro 179€

Apache Tomcat 0€

Apache Maven 0€

Eclipse 0€

Sublime Text 0€

Protegé 0€

Sakai LMS 0€

TOTAL 1399€

Tabla 14. Coste económico material del proyecto.

5.4.2 Costes humanos.

En este apartado vamos a tratar los costes derivados del trabajo

humano invertido en este proyecto.

Para la realización de este proyecto se estima necesaria la

participación de los siguientes tres recursos técnicos: un analista, un

programador y un administrador. La función de cada uno de ellos se

recoge a continuación:

Analista: se encargará de la captura de requisitos, análisis de

los mismos y diseño de la solución.

Programador: será el encargado del desarrollo de la solución.

Técnico de implantación: su cometido será realizar la

implantación de la solución, así como las diferentes pruebas que

requiere el proyecto.

83

La tabla 15 recoge el coste por hora de cada uno de los recursos.

Estos costes han sido estimados en base a la experiencia profesional del

alumno y confirmados realizando una media entre los salarios ofertados

en las principales páginas de búsqueda de empleo a nivel nacional.

Recurso Coste

Analista 12.00€/hora

Programador 10.00€/hora

Técnico de implantación 8.00€/hora

Tabla 15. Conste personal del proyecto

Si bien, los recursos citados anteriormente son necesarios para la

realización del proyecto, todo el trabajo será realizado por el autor de este

trabajo fin de grado, realizado la funciones específicas de cada uno de los

roles, según necesidades del desarrollo.

En la tabla 16, se muestra el coste de cada una de las tareas, así como

el recurso al que han sido asignadas.

Tabla 16. Coste desglosado por tareas del proyecto

84

Como podemos observar, el coste total, en recursos humanos, del

proyecto, es de 18592€, con un total de 206,5 días de trabajo.

5.4.3 Costes totales

La tabla 17 nos muestra un resumen de los costes totales de

desarrollar este proyecto.

Concepto Coste

Materiales 1399€

Humanos 18592€

Costes Indirectos 1977€

Total 21968€

Tabla 17. Coste total del proyecto

Como podemos observar, el coste total de desarrollar este proyecto

sería de 21968 €.

5.5 Valoración real de la dedicación

En este apartado vamos a valorar el tiempo real invertido en la

realización de este proyecto, y detallaremos la desviación sufrida, así

como los motivos de la misma.

Si bien el proyecto se había planificado para su finalización en

septiembre de 2014, debido a diversos problemas de índole personal

padecidos por el autor de este trabajo fin de grado, en el mes de julio de

2014 el proyecto quedó indefinidamente parado. Habiéndose retomado el

mismo durante el mes de marzo de 2015.

El siguiente diagrama de Gantt (Figuras 9 y 10) muestra una

planificación de las tareas actualizada a la nueva situación.

85

Figura 9. Diagrama de Gantt real (A)

Figura 10. Diagrama de Gantt real (B)

86

Como podemos ver, las tareas tuvieron que ser temporalmente

desplazadas, si bien el tiempo asignado a cada una de ellas se mantiene

invariable. Por tanto, como vemos, el proyecto comenzó, como estaba

previsto, el día 1 de febrero de 2014, quedando detenido el día 3 de julio

de ese mismo año. No fue hasta marzo de 2015 cuando el proyecto fue

retomado desde el punto en el que lo habíamos dejado.

La tabla 18 nos muestra la planificación con las fechas ajustadas a la

nueva situación.

Tabla 18. Planificación de tareas real

La figura 11, nos muestra la desviación sufrida por el proyecto desde

su inicio hasta su finalización.

87

Figura 11. Desviación temporal del proyecto

Como podemos ver, la desviación producida ha sido de 259 días, si

bien, en caso de un desarrollo normal del proyecto, la planificación inicial

se habría cumplido.

En cuanto al coste real del proyecto, al haber estado totalmente parado

su desarrollo durante el lapso indicado, el coste inicial se mantiene

invariable, ya que se considera que no se han pagado recursos humanos

durante el tiempo de parada.

0 50 100 150 200 250 300 350 400 450 500

Estimacion Inicial

Desempeño real

Días

Desviación temporal del proyecto

Estudio Previo Analisis y diseño

Preparación del entorno de desarrollo Implementacion y desarrollo

Parada Pruebas

Puesta en marcha

88

89

6. DESARROLLO DEL PROYECTO

En este apartado vamos a tratar, de forma individual, cada uno de los

desarrollos de este trabajo fin de grado.

6.1 Desarrollo de la Ontología OntoSakai

En este apartado vamos a detallar el desarrollo de OntoSakai,

siguiendo la metodología Methontology. Si bien esta metodología está

orientada al desarrollo de ontologías partiendo de cero, nosotros

contamos con las ontologías previamente desarrolladas desde el

departamento, por tanto, vamos a adaptar Methontology a las

necesidades desprendidas de la integración de las ontologías.

6.1.1 Glosario de términos.

En este apartado vamos a crear un glosario de términos de OntoSakai,

este glosario se desprende tanto de la información aportada por las

ontologías previamente desarrolladas como por nuevos términos

necesarios para la integración de las mismas.

Nombre Sinónimos Descripción Tipo

Participant Usuario Usuario con acceso al entorno LMS Concepto

Student Estudiante Usuario con rol de estudiante con

acceso al entorno LMS

Concepto

Lecturer Docente Usuario con rol de docente con

acceso al entorno LMS

Concepto

Qualificación Calificación Resultado obtenido por un

estudiante en una tarea en concreto

Concepto

Subject Asignatura Representa los “Sitios” en Sakai,

estos a su vez representan

asignaturas concretas en cursos

académicos determinados

Concepto

Tool Herramienta Herramienta contenida dentro de un Concepto

90


sitio

EvaluativeTo

ol

Herramienta

evaluable

Herramienta susceptible de

contener elementos calificables

Concepto

Tests -- Herramienta de test dentro de Sakai Concepto

Assignments Tareas Herramienta de tareas dentro de

Sakai

Concepto

Colaborative

tool

Herramientas

colaborativas

Herramienta participativa dentro de

Sakai

Concepto

Chat -- Herramienta de chat dentro de

Sakai

Concepto

Discussion

Forum

Foro Herramienta de foros de discusión

dentro de Sakai

Concepto

Resources Recursos Herramienta de “Recursos” dentro

de Sakai

Concepto

Annuncement

s

Anuncios Herramienta de anuncios dentro de

Sakai.

Concepto

ToolElement Elemento de

herramienta

Define instancias contenidas dentro

de una tool determinada

Concepto

Evaluative

ToolElement

Elemento de

herramienta

evaluativa

Define instancias contenidas dentro

de una “EvaluativeTool”

determinada

Concepto

TopicItem -- Define un concepto dentro una

determinada área de conocimiento

Concepto

Topic -- Define un área de conocimiento Concepto

Event Evento Eventos generados por los usuarios

con el uso habitual de Sakai

Concepto

Profile Perfil Define perfiles para los usuarios de

Sakai

Concepto

StudentProfil

e

Perfil de

estudiante

Define perfiles determinados para

los estudiantes.

Concepto

LecturerProfil

e

Perfil de

docente

Define perfiles específicos para los

docentes.

Concepto

DNI -- DNI del usuario Atributo

de

instancia

91


Nombre -- Nombre descriptivo Atributo

de

instancia

Apellidos -- Apellidos del usuario Atributo

de

instancia

UsuarioID -- ID dentro de Sakai para un usuario Atributo

de

instancia

Nota -- Valor numérico que indica la

calificación obtenida

Atributo

de

instancia.

Créditos -- Número de créditos de Atributo

de

instancia

Descripción -- Breve descripción del concepto Atributo

de

instancia

ToolID -- ID dentro de Sakai para una

herramienta

Atributo

de

instancia

EventID -- ID del evento generado por Sakai Atributo

de

instancia

Hora -- Hora a la que se produce un evento Atributo

de

instancia

Fecha -- Fecha en la que se produce un

evento

Atributo

de

instancia

Ocurrences -- Numero de repeticiones de un

evento concreto, dentro de una

determinada herramienta, producido

por un cierto usuario

Atributo

de

instancia

PerfilID -- ID de un perfil determinado. Atributo

92


de

instancia.

belongsTo

(ToolElement,

Tool)

-- El elemento de la herramienta

pertenece a una herramienta.

Relación

consistsOf

(Topic,

TopicItem)

-- El topic está compuesto por

topicItems.

Relación

IsContainedIn

(TopicItem,

Topicl)

-- Relación inversa a ConsistsOf Relación

IsEnrolled

(Participant,

Subject)

-- El participante estudia/imparte una

asignatura

Relación

isObtainedBy

(Student,

Qualification)

-- La calificación pertenece a un

estudiante

Relación

isRelatedToT

oolElement

(ToolElement,To

olElement)

-- El ToolElement se relaciona con

otro ToolElement

Relación

profileRequire

s

(Profile,

ToolElement)

-- ToolElement recomendado para

este perfil.

Relación

referrersTo

(ToolElement,

TopicItem)

-- El ToolElement hacer referencia a

un topicItem

Relación

hasProfile

(Participant,

Profile)

-- El participante tiene un perfil Relación

Incorporates

(Subject, Tooll)

-- La asignatura incorpora

herramientas

Relación

isObtainedIn

(Qualification,

Subjectl)

-- La calificación se ha obtenido en

una asignatura

Relación

isProducedBy

(Event,

Participant)

-- Un evento es producido por un

usuario concreto

Relación

93


isProducedO

n

(Event,

ToolElement)

-- Un evento es producido en el

contexto de un ToolElement

concreto.

Relación

Tabla 19. Glosario de términos

6.1.2 Taxonomías de conceptos

En este apartado vamos a desarrollar taxonomías de los conceptos

citados en el apartado anterior.

Una taxonomía es un tipo de vocabulario controlado en que todos los

términos están conectados mediante un modelo estructural (jerárquico,

arbóreo, facetado, etc.) y especialmente orientado a los sistemas de

navegación, organización y búsqueda de contenidos de los sitios web.

El modelo ontológico OntoSakai está formado por las siguientes

taxonomías de términos.

a) Como se muestra en la figura 12, el concepto tool tiene las

siguientes subclases: Resoruces con subclases test y assignments,

EvaluativeTool, ColaborativeTool con subclases chat y discussion

forum, y Annuncements.

94

Figura 12. Diagrama de taxonomía herramienta

b) La figura 13 muestra el concepto Profile, y sus subclases

StudentProfile y LecturerProfile.

Figura 13. Diagrama de taxonomía perfilado.

95

c) La figura 14 muestra el concepto participante, y sus subclases

student y lecturer.

Figura 14. Diagrama de taxonomía Participante

d) Por último, la figura 15 muestra la taxonomía agrupada del resto de

conceptos de OntoSakai. Qualification, Event, TopicItem, Subject y

ToolElement con su subclase EvaluativeToolElement.

Figura 15. Diagrama de taxonomía de más alto nivel.

96

6.1.3 Diagrama de relaciones binarias

En este apartado se definen las relaciones binarias entre los conceptos

y sus relaciones inversas.

Como podemos ver, en cada diagrama, contamos con dos conceptos,

representados por su nombre de concepto dentro de un recuadro, y dos

relaciones, la relación directa (representada en rojo) y la relación inversa

(en color verde).

Figura 16. Relación Participante - Asignatura

Figura 17. Relación Evento - Participante

Figura 18. Relación Evento - ToolElement

97

Figura 19. Relación Estudiante - ToolElement

Figura 20. Relación Calificación - Estudiante

Figura 21. Relación Calificación - EvaluativeToolElement

Figura 22. Relación Asignatura - Herramienta

98

Figura 23. Relación ToolElement - Herramienta

Figura 24. Relación ToolElement -TopicItem

Figura 25. Relación Topic - TopicItem

.

Figura 26. Relación Perfil - ToolElement

99

Figura 27. Relación Participante - Perfil

Figura 28. Relación ToolElement – ToolElement

En el caso concreto de la relación isRelatedTo, cabe destacar que se

trata de una relación reflexiva, es decir, relaciona un concepto consigo

mismo. Para ilustrarlo pondremos que, por ejemplo, tenemos el recurso

“Tema1” de la asignatura “IC”, que está relacionado con “Practica 1” de

esa misma asignatura quedándonos una relación entre ambas instancias

como la representada en la figura 29.

Figura 29. Ejemplo relación isRelatedTo

100

6.1.4 Diccionario de conceptos

El objetivo de este apartado es especificar cuáles son las propiedades

que describen cada concepto de la taxonomía, las relaciones del

diagrama de relaciones binarias y las instancias de cada uno de los

conceptos

Concepto Atributos de

clase

Atributos de

instancia

Relaciones

Participant -- Nombre

Apellidos

DNI

isEnrolled

hasProfile

Student -- Nombre

Apellidos

DNI

isObtainedBy

studentRequires

Lecturer -- Nombre

Apellidos

DNI

--

Qualificación -- Nota isObtainedBy

IsObtainedIn

Subject -- Nombre

Créditos

Descripción

isEnrolled

incorporates

Tool -- -- Incorporates

belongsTo

Evaluative Tool -- -- isObtainedIn

Tests

-- -- --

Assignments -- -- --

Colaborative

tool

-- -- --

Chat -- -- --

Discussion

Forum

-- -- --

Resources -- -- --

101

Concepto Atributos de

clase

Atributos de

instancia

Relaciones

Annuncements -- -- --

ToolElement -- -- belongsTo

isRelatedTo

refersTo

studentRequires

profileRequires

Evaluative

ToolElement

-- -- isObtainedIn

TopicItem -- -- refersTo

consistsOf

Topic -- -- consistsOf

Event -- Hora

Fecha

Ocurrencias

isProducedOn

isProducedBy

Profile -- hasProfile

profileRequires

StudentProfile -- -- --

LecturerProfile -- -- --

Tabla 20. Diccionario de conceptos

6.1.5 Detalle de las relaciones binarias

En este apartado vamos a especificar en detalle cada relación binaria.

Relación Origen Cardinalida

d

Destino Relación

Inversa

isEnrolled Participant N Subject hasEnrolled

isProducedBy Event 1 Participant Produces

isProducedOn Event 1 ToolElement Produces

studentRequir

es

Student N ToolElement RequiredBy

isObtainedBy Qualification N Student Obtains

isObtainedIn Qualification 1 EvaluativeToolEle Has

102

ment

Incorporates Subject N Tool isIncorporatedI

n

belongsTo ToolElement 1 Tool Contains

refersTo ToolElement N TopicItem isReferedby

consistsOf Topic N TopicItem isContainedIn

profileRequires Profile N ToolElement isRequiredBy

hasProfile Participant 1 Profile belongsTo

isRelatedTo ToolElement N ToolElement isRelatedTo

Tabla 21. Relaciones Binarias

6.1.6 Descripción de los atributos de instancia

En este apartado se describen con detalle todos los atributos de

instancia aportados en el glosario de términos.

Atributo Concepto Tipo Rango de

valores

Cardinalidad

DNI Student

Lecturer

String -- (1,1)

Nombre Student

Lecturer

Subject

String -- (1,1)

Apellidos Student

Lecturer

String -- (1,1)

UsuarioID Student

Lecturer

String -- (1,1)

Nota Qualification Float 0.0-10.0 (1,1)

Creditos Subject Float 0. 0… (1,1)

Descripción Subject String -- (1,1)

ToolID Tool String -- (1,1)

EventID Event String -- (1,1)

Hora Event String -- (1,1)

Fecha Event String -- (1,1)

Ocurrences Event Int 1 … (1,1)

103

PerfilID Profile String -- (1,1)

Tabla 22. Atributos de instancia

6.1.7 Descripción de atributos de clase

En este modelo ontológico no se han especificado atributos de clase.

6.1.8 Descripción de las constantes

En este modelo ontológico no se han especificado constantes

6.1.9 Descripción de las instancias

En este apartado vamos a describir ejemplos de instancias relevantes

para el dominio del modelo. En nuestro caso, las relacionadas con los

recursos y su recomendación.

Instancia Concepto Atributo Valor

5e2f19fe-96c7-4d23-9089-

0847b2ca2358

Asignatura Nombre IC

Descripción Ingeniera del

conocimiento

Creditos 6

5e2f19fe-96c7-4d23-9089-

0847b2ca2358/Portada.png

ToolElement -- --

5e2f19fe-96c7-4d23-9089-

0847b2ca2358/Resources

Resources -- --

Ontologies Topic -- --

SPARQL TopicItem -- --

Tabla 23. Instancias

104

6.1.10 Conclusiones OntoSakai

Una vez concluido el análisis diseño del modelo ontológico podemos

destacar que ha sido necesaria la creación de nuevas relaciones como

son:

- refersTo: Necesaria para indicar a que topicItems hace

referencia un ToolElement en concreto.

- hasProfile: Necesaria para indicar que un usuario tiene un

perfil en particular.

- isProducedOn: Indica en que elemento concreto se ha

producido un evento en particular.

- isProducedBy: Indica que usuario ha generado un evento.

- isObtainedIn: Necesaria para indicar en que elemento

evaluable se ha obtenido una calificación en particular.

- profileRequires: Relaciona un perfil con un ToolElement en

particular. Necesario para recomendaciones a nivel de

perfil.

- studentRequires: Necesario para recomendaciones

personalizadas a cada estudiante.

Ha sido de igual modo necesario modificar el diseño de los atributos

dentro de las ontologías. En este caso, hemos eliminado los siguientes

atributos de instancia por considerarlos innecesarios y redundantes.

- ToolID: En nuestro diseño, la ID de la tool será el nombre

de la instancia dentro de la ontología.

- UsuarioID: Al igual que ocurre en el caso anterior, el ID del

usuario será el nombre de la instancia en la Ontología.

- AsignaturaID: En este caso, al igual que en los dos

anteriores, usamos como nombre de la instancia el ID de la

asignatura, por lo que sería redundante almacenarlo como

atributo.

105

6.1.11 Implantación de la ontología en Protegé.

Como se explicó en el capítulo 2.3.1, utilizaremos el software Protegé

para la implantación del modelo ontológico en el lenguaje OWL. Los

pasos que hemos seguido para la implantación han sido los siguientes.

a) Importación de las ontologías disponibles: Como hemos

comentado anteriormente, partíamos de la base de una serie de

ontologías previamente desarrolladas. Por tanto, el primer paso es

integrarlas entre sí. Para ello hacemos uso del asistente de

importación de Protegé, tal como muestra la figura 30.

Figura 30.Importación Protegé

b) Creación de nuevas relaciones: El segundo paso ha sido crear

nuevas relaciones para integrar todo en un modelo ontológico

común. En la figura 31 pueden verse las relaciones creadas

106

Figura 31. ObjectProperties Protege

La figura 32 muestra en detalle las propiedades de una relación.

Como podemos ver contamos con los siguientes atributos o

propiedades aplicables a una relación:

EquivalentTo: Indica si esta relación es equivalente a otra y,

por tanto, podrían inferirse datos a través de ambas.

SubPropertyOf: Indica si esta relación es una subrelación de

otra superior, por ejemplo, podríamos tener alumnos en una

asignatura y como subrelación podríamos tener online y

presencial.

InverseOf: Indica si cuenta con una relación inversa y, si es

así, muestra de cual se trata.

Domains: Hace referencia al concepto del que parte la

relación.

Ranges: Hace referencia al concepto destino de esta

relación.

107

Figura 32. Detalle propiedades Protegé

c) Adecuación de los atributos: El tercer paso ha sido adecuar los

atributos tal y como se indica en el apartado de conclusiones y

asignarlos a los diferentes conceptos. La figura 33 muestra en

detalle un atributo asignado. Como podemos ver contamos con las

siguientes propiedades aplicables a un relación

EquivalentTo: Indica si existe un atributo equivalente a este.

SubPropertyOf: Indica si este atributo es una especificación

de un atributo de mayor rango.

Domains: Aquí se muestran los conceptos sobre los que se

aplica este atributo en particular.

Ranges: Indica el tipo de valor que puede adquirir este

atributo, podríamos asemejarlo a un tipo de variable en un

lenguaje de programación tradicional.

108

Figura 33. Atributos de concepto Protegé

d) Creación de las instancias: El último paso habría de ser insertar

las instancias dentro de nuestra ontología, sin embargo, en nuestro

caso, será el servicio Web el encargado de hacer esta tarea.

6.2 OntoSakaiWS

6.2.1 Especificación de requisitos de software.

En este apartado abarcamos la especificación de requisitos del servicio

Web OntoSakaiWS, encargado de actuar de intermediario ente OntoSakai

y las herramientas desarrolladas para Sakai.

6.2.1.1 Propósito

El objetivo es definir de manera clara y concisa las funcionalidades y

restricciones del servicio web OntoSakaiWS para uso de los

desarrolladores de software.

Este documento constituirá la base del equipo de desarrollo, el cual

debe seguir las pautas presentes en este documento para la realización

de las funcionalidades especificadas.

109

6.2.1.1.1 Ámbito del sistema

El servicio Web a desarrollar se denominará “OntoSakaiWS”. Esta

aplicación proporcionará una interfaz para la gestión de las ontologías que

conforman OntoSakai, la cual permitirá hacer consultas, ediciones y

nuevas inserciones dentro del catálogo de OntoSakai.

El fin último de este desarrollo es proporcionar un sistema mediante el

cual, una tercera aplicación, pueda tomar el control de las ontologías y

tratarlas en función a los datos de entrada y las operaciones solicitadas

por el usuario.

Esta aplicación se plantea como un modelo de base, escalable

fácilmente, sobre el que incluir futuras necesidades y especificaciones.

6.2.1.1.2 Definiciones, acrónimos y abreviaturas

Este apartado recoge las definiciones, acrónimos y abreviaturas que se

utilizan en el presente documento, con el fin de facilitar la comprensión y

la lectura del mismo:

Servicio Web: tecnología que utiliza un conjunto de protocolos y

estándares que sirven para intercambiar datos entre

aplicaciones. Distintas aplicaciones de software desarrolladas en

lenguajes de programación diferentes, y ejecutadas sobre

cualquier plataforma, pueden utilizar los servicios web para

intercambiar datos en redes de ordenadores como Internet.

Cliente: es una máquina o proceso que accede a recursos y

servicios de forma remota, ofrecidos por un servidor.

Ontología: esquema conceptual dentro de uno o varios

dominios dados; con la finalidad de facilitar la comunicación y el

intercambio de información entre diferentes sistemas y

entidades.

110

OntoSakai: Modelo ontológico formado por una serie de

ontologías que representa el contenido semántico del dominio

de un LMS.

Servidor: es un sistema que, formando parte de una red, ofrece

servicios a otras máquinas denominadas clientes, también se

conoce con el nombre de host.

6.2.1.1.3 Visión general del documento ERS

El documento recoge los requisitos necesarios para el desarrollo del

servicio web OntoSakai según el estándar "IEEE Recommended Practice

for Software Requirements Specications (IEEE/ANSI 830 -1993).

El documento se basa en las entrevistas realizadas con los directores

del presente trabajo fin de grado, así como en el estudio y análisis de la

documentación existente.

6.2.1.2 Descripción general

Esta sección del documento reflejará las características del presente

desarrollo.

6.2.1.2.1 Perspectiva del producto

Con el objetivo de dotar a los LMS con características de

personalización y recomendación de ha desarrollado un modelo

ontológico denominado “OntoSakai”.

Tomando como punto de partida dicho modelo ontológico, se

desarrollará este servicio web con la pretensión de servir como base para

implementar estos servicios de recomendación y personalización en el

LMS Sakai.

111

Este desarrollo servirá como base sobre la cual construir nuevas

aplicaciones que aporten de conocimiento experto al entorno de Sakai.

6.2.1.2.2 Funciones del desarrollo

Este apartado detallará las funciones básicas, en base a las cuales se

desarrollará el servicio web.

a) La aplicación debe ser capaz de leer el modelo ontológico contenido

en las diferentes ontologías que componente OntoSakai.

b) La aplicación debe ser capaz de editar el modelo ontológico,

creando en él nuevas instancias de las clases definidas y

modificando instancias ya existentes con el fin de añadir nueva

información.

c) La aplicación debe ofrecer información formateada e interpretable

desde una tercera aplicación, de los datos contenidos en

OntoSakai.

6.2.1.2.3 Características de los usuarios

En este caso concreto, los usuarios de esta aplicación serán

herramientas de software que consumirán los servicios ofrecidos por el

sistema.

6.2.1.2.4 Restricciones

Se han recogido las siguientes restricciones que deben tenerse en

cuenta a la hora de desarrollar el proyecto.

El desarrollo debe cumplir con los estándares de la industria de

ingeniería del software.

La información ofrecida por el sistema debe tener un formato

homogéneo de forma que la lectura pueda estandarizarse.

112

El sistema debe ofrecer mecanismos para el control de la

integridad referencial dentro de la ontología.

6.2.1.2.5 Suposiciones y dependencias

El desarrollo se realiza con un entorno de desarrollo integrado

como es Eclipse Java EE IDE for Web Developers.

El servicio web debe correr en un servidor de aplicaciones, en

nuestro caso hemos usado Apache Tomcat, debido a que este

servidor se presenta como uno de los requisitos para el

funcionamiento de Sakai.

El servicio web debe contener, entre sus dependencias, el

modelo ontológico OntoSakai, formado por cuatro ontologías. De

modo que pueda atacarlas cuando sea necesario.

Se ha seleccionado el lenguaje de programación Java porque

representa un estándar multiplataforma, y además, posibilita

crear aplicaciones mantenibles con código reutilizable.

Para el manejo de ontologías hemos optado por usar el

framework Apache Jena, que nos permite atacar las ontologías

de manera sencilla y eficiente.

6.2.1.2.6 Requisitos futuros

Este servicio web se desarrolla como base sobre la que construir una

integración completa de OntoSakai con el LMS Sakai.

Por cuestiones de tiempo, en el presente desarrollo nos hemos

centrado en las funcionalidades relacionadas con la recomendación de

recursos dentro del campus virtual.

113

Para desarrollos futuros habría que escalar las funcionalidades de este

servicio web, incluyendo el resto del ámbito de OntoSakai.

6.2.1.3 Requisitos específicos.

Esta sección especificará con detalle los requisitos que debe poseer

esta aplicación.

6.2.1.3.1 Interfaces externas

No se han definido interfaces externas para esta aplicación.

6.2.1.3.2 Funciones

En este apartado definiremos las funciones específicas que debe

cumplir esta aplicación.

RF-1: Añadir, modificar y listar asignaturas.

RF-2: Añadir, modificar y listar herramientas de una asignatura.

RF-3: Añadir, modificar y listar elementos específicos de una

herramienta concreta.

RF-4: Añadir, modificar y listar Topics.

RF-5: Añadir, modificar y listar TopicItems relacionados con un

topic en concreto.

RF-6: Relacionar recursos con topicItems.

RF-7: Relacionar recursos con Asignaturas.

RF-8: Relacionar recursos con otros recursos.

RF-9: Realizar recomendaciones de recursos según sus

relaciones definidas.

RF-10: Mantener la integridad referencial del modelo ontológico.

114

6.2.1.3.3 Requisitos de rendimiento.

La aplicación debe garantizar unos niveles de rendimiento altos, ya que

es la base sobre la que se construirán herramientas para LMS que deben

responder con rapidez y fluidez.

Las lecturas de datos no se demorarán más de 1 segundo.

Las inserciones de datos no se demorarán más de 3 segundos.

6.2.1.3.4 Restricciones de diseño.

No se han definido restricciones de diseño para el desarrollo de esta

aplicación.

6.2.1.3.5 Atributos del sistema.

El servicio web desarrollado deberá cumplir con las características

listadas a continuación.

Deberá ofrecer datos en un formato fácilmente tratable por las

aplicaciones cliente, tanto integradas con Sakai como externas

al citado LMS.

El servicio web debe poder instalarse en cualquier servidor de

aplicaciones, independientemente del sistema operativo sobre el

que se esté ejecutando.

El servicio web debe desarrollarse de forma que sea fácilmente

escalable a fin de facilitar futuros desarrollos sobre el mismo.

115

6.2.1.3.6 Otros requisitos

No se han definido otros requisitos a parte de los ya definidos con

anterioridad.

6.2.1.4 Definición de los actores

ACT-01 OntoSakai Resources

Versión 1.0

Autor Alberto Miguel Oliva Molina

Descripción Herramienta subida de recursos

Comentarios Debe ser capaz de realizar todas las

operaciones de creación de elementos

y listado de los mismos

Tabla 24. Definición Actor 1 OntoSakaiWS

ACT-02 OntoSakai Browser

Versión 1.0


Descripción Herramienta descarga y recomendación

de recursos

Comentarios Debe ser capaz de realizar todas las

operaciones de listado de elementos y

de recomendación de recursos.

Tabla 25. Definición actor 2 OntoSakaiWS

116

6.2.1.5 Casos de uso

En este apartado se muestra un diagrama de casos de uso (figura 34)

del funcionamiento del servicio web.

Figura 34. Diagrama casos de uso OntoSakaiWS

Debido a su extensión, las especificaciones de los casos de uso se

recogen en el "ANEXO A1".

6.2.1.6 Diagramas de secuencia

Un diagrama de secuencia muestra la interacción en forma de gráfico,

el cual consta de dos dimensiones; La dimensión vertical es el eje de

tiempo, que avanza hacia el final. La dimensión horizontal, que muestra

los roles que representan los objetos.

117

Los diagramas de secuencia se recogen en el "ANEXO B1". Cabe

destacar que se ha planteado un diagrama de secuencia por cada caso

de uso.

6.2.2 Diseño de la solución

En presente aparado detalla el diseño de la solución Para el caso de

OntoSakaiWS. El diseño de la solución incluye el diagrama de clases y el

diseño de la interface.

6.2.2.1 Modelo de clases

En el presente apartado detallaremos el modelo de clases de

OntoSakaiWS.

La figura 35 muestra el modelo de clases de OntoSakaiWS.

118

Figura 35. . Diagrama de clases OntoSakaiWS

Como podemos observar, hemos creado tres clases:

OntManager: Es la encargada de interactuar a bajo nivel con el

modelo ontológico de OntoSakai.

WSInterface: Es la clase que contiene todos los métodos

públicos del servicio Web. Instancia a la clase OntManater para

ello.

CommonFunctions: Esta clase contiene una serie de funciones

auxiliares que son empleadas por las otras dos clases, tales

como formatear los datos o realizar la escritura física de la

ontología.

119

Las clases de la API que hemos usado para el desarrollo han sido:

QueryExecution: Encargada de ejecutar las consultas

SPARQL.

ValidityReport: Genera un reporte del estado del modelo tras la

carga.

Query: Las instancias de esta clase son las consultas SPARQL

propiamente dichas.

Individual: Las instancias de esta clase son los individuales

(Instancias de conceptos) del modelo.

Propertie: Representa las data properties de los individuales.

ResultSet: Necesario para almacenar los resultados de las

consultas SPARQL.

OntClass: Representa los conceptos o clases dentro del

modelo.

OntModel: Representa el modelo completo.

6.2.2.2 Diseño de la interfaz.

OntoSakaiWS carece de interface gráfica propia.

6.2.2.3 Plan de pruebas unitarias

Para el caso del servicio web, se han planificado pruebas para cada

uno de los casos de uso, de forma que tengamos la certeza de que, en

cualquier caso, su funcionamiento es el esperado. La tabla 26 muestra las

pruebas unitarias planificadas.

120

ID Descripción Caso de

uso

Propósito Superada

CP-001 Creación de

nuevas

Asignaturas

CU-01 Crear

Asignatura

Comprobar el

correcto

funcionamiento de la

inserción de

asignaturas a través

del servicio web

Sí

CP-002 Creación de

nuevas

herramientas

CU-02 Crear

Herramienta

Comprobar el

correcto


inserción de

herramientas a

través del servicio

web

Sí

CP-003 Creación de

nuevos topics

CU-03 Crear

Topic

Comprobar el

correcto


inserción de topics a


web

Sí

CP-004 Creación de

nuevos topicItem

CU-04 Crear

TopicItem

Comprobar el

correcto


inserción de

topicItems a través

del servicio web

Sí

CP-005 Creación de

nuevos recursos

CU-05 Crear

Recurso

Comprobar el

correcto


inserción de recursos

a través del servicio

web

Sí

CP-006 Listado de todos

los topics

existentes en el

CU-06

Obtener

topics

Comprobar el

correcto listado de

todos los topics

Sí

121

sistema existentes dentro del

modelo ontológico a


Web


los recursos

existentes en el

sistema

CU-07

Obtener

recursos

Comprobar el

correcto listado de

todos los recursos

dentro del ontológico

a través del servicio

Web

Sí


los topicItems

relacionados con

un topic en

particular

CU-08

Obtener

topicItems

contenidos

en Topic

Comprobar el

correcto listado de

todos los topicItems

contenidos en un

topic.

Sí


los topicItem

referidos por un

recurso en

particular.

CU-09

Obtener

TopicItems

referidos por

un recursos

Comprobar el

correcto listado de

los topicItems

relacionados con un

recursos en

particular

Sí

CP-010 Obtener el Topic

al que pertenece

un determinado

topicItem

CU-10

Obtener

topic al que

pertenece

topicItem

Comprobar la

correcta devolución

del Topic en el que

está contenido un

topicItem

Sí

CP-011 Obtener todos

los recursos

relacionados con

una asignatura

CU-11

Obtener

recursos de

una

asignatura

Comprobar el

correcto listado de

todos los recursos

pertenecientes a una

asignatura concreta

Sí

CP-012 Obtener el

nombre de una

asignatura a

través de su ID

CU-12

Obtener

nombre

asignatura

Comprobar la

correcta devolución

del nombre de una

asignatura a través

de su ID

Sí

122

CP-013 Obtener un

listado de todas

las asignaturas

CU-013

Obtener

Asignaturas

Comprobar el

correcto listado de

todas las asignaturas

existentes en el

modelo ontológico

Sí

CP-014 Obtener listado

de recursos

relacionados a

partir de un

recurso concreto

CU-14

Obtener

recursos

relacionados

con recurso

Comprobar el

correcto listado de

recursos

relacionados

partiendo de un

recurso en particular

Sí

CP-015 Obtener un

listado de

recursos

relacionados a

partir de un

topicItem

CU-15

Obtener

recursos

relacionados

topicItem

Comprobar el

correcto listado de

recursos

relacionados con un

topicItem

Sí

CP-016 Crear relación

consistsOf

CU-16 Crear

relación

consistsOf

Comprobar la

correcta creación de

la relación

Sí


refersTo

CU-17 Crear

relación

refersTo

Comprobar la


la relación

Sí


isRelatedTo

CU-18 Crear

relación

isRelatedTo

Comprobar la


la relación

Sí


belongsTo

CU-19 Crear

relación

belongsTo

Comprobar la


la relación

Sí

Tabla 26. Casos de prueba OntoSakaiWS.

123

6.2.3 Pruebas de esfuerzo

Para el caso concreto de OntoSakaiWS se han considerado una serie

de pruebas de esfuerzo debido a que este componente será el que más

carga de trabajo soporte.

Las pruebas de esfuerzo han consistido en una serie de operaciones,

con el objetivo de saturar el servicio o bien tratar de corromper las

ontologías mediante la introducción de gran cantidad de datos. En la tabla

27 se especifican las pruebas realizadas.

ID Descripción Propósito Superada

CP-001 Inserciones

masivas de

datos simples.

Comprobar el comportamiento del

servicio web ante la inserción de

datos simples durante un periodo

prolongado de tiempo.

Sí

CP-002 Inserciones

masivas de

datos y creación

de relaciones

de los mismos.

Comprobar la capacidad del

servicio web para soportar una

carga de procesamiento alta,

consistente en crear nuevas

instancias de las entidades y

relacionarlas entre sí.

Sí

CP-003 Inserciones

masivas de

datos y creación

de relaciones

de los mismos.

Posterior

eliminación de

entidades y

comprobación

de las

relaciones.

Comprobar la capacidad del servicio web para soportar una carga de procesamiento alta, consistente en crear nuevas instancias de las entidades y relacionarlas entre sí. Posteriormente han sido eliminadas y vueltas a crear para comprobar el correcto funcionamiento de la eliminación.

Sí

Tabla 27. Pruebas de esfuerzo.

124

6.2.4 Despliegue

En este apartado vamos a detallar el despliegue de este servicio Web

mediante el uso de un diagrama de despliegue UML mostrado por la

figura 36.

Figura 36. Diagrama de despliegue OntoSakaiWS

6.3 OntoSakai Resources

6.3.1 Especificación de requisitos de software.

En este apartado abarcamos la especificación de requisitos de la

herramienta de Sakai Ontosakai Resources.

6.3.1.1 Propósito


restricciones de la herramienta OntoSakai Resources para uso de los


125





La herramienta a desarrollar se denominará “OntoSakai Resources”.

Esta herramienta proporcionará una interfaz gráfica para la gestión de las

recursos dentro del LMS Sakai, la cual permitirá a los docentes crear

nuevo contenido dentro de la plataforma, asociarlo con otros recursos ya

existentes y clasificarlos mediante el uso de TopicItems.

El fin último de este desarrollo es proporcionar un sistema mediante el

cual podamos dotar a los recursos subidos al campus virtual de

información semántica que será utilizada por otras aplicaciones para

realizar recomendaciones a los usuarios.





Docente: hace referencia al personal de la universidad

encargado de subir los recursos.

Alumno: usuario que consumirá los recursos del campus y al

cual están orientados los servicios de recomendación.

Recurso: elemento subido al campus, que contendrá tanto el

documento proporcionado por el docente como la

metainformacion semántica relacionada con el mismo.

Herramienta: referido a las aplicaciones integradas dentro de

Sakai que ofrecen un servicio o funcionalidad.

LMS: sistema de gestión del aprendizaje. Entorno que facilita el

proceso de aprendizaje de los alumnos.

126

Topic: área de conocimiento compuesta por diversos temas.

TopicItem: elemento que define un tema determinado dentro de

un área de conocimiento especifica.


El documento recoge los requisitos necesarios para el desarrollo de la

herramienta OntoSakai Resources según el estándar "IEEE

Recommended Practice for Software Requirements Specications

(IEEE/ANSI 830 -1993).






desarrollo.


Con el objetivo de permitir la recomendación de recursos por parte del

LMS a los alumnos, es necesario dotar a cada recurso con una serie de

información semántica.

Esta información está constituida, por los recursos existentes que se

relacionen directamente con nuestro recurso, y los topicItems a los que el

recurso pertenezca.

El objetivo de este herramienta es el de permitir a los docentes

generar, de forma sencilla e intuitiva, estos recursos y su información

semántica relacionada.

127

Los elementos generados por esta aplicación, serán de utilidad en la

herramienta de recomendación.



desarrollará el servicio web.

a) Todo usuario con privilegios de docente podrá acceder a esta

herramienta y crear nuevo contenido.

b) Los usuarios con privilegios deben ser capaces de crear nuevos

topics y/o topicItems

c) La aplicación debe valerse de OntoSakaiWS para gestionar la


d) La aplicación debe permitir la escritura en la base de datos propia

de Sakai, a fin de permitir el uso de estos recursos por las

aplicaciones incorporadas en el núcleo de Sakai.


Las características de los usuarios son las siguientes:

Docente: Será el encargado de generar los nuevos recursos así

como de dotarlos de información semántica. Requiere

conocimientos básicos sobre el funcionamiento de nuestra

herramienta así como los conceptos relacionados con la

información semántica a proporcionar.

128






La interface de usuario debe ser sencilla e intuitiva.

Se debe controlar la introducción manual de datos por parte del

usuario a fin de evitar información no valida.

Valiéndonos de las funciones de control de OntoSakaiWS se

debe garantizar la integridad referencial antes de cada nueva

inserción.




La herramienta debe funcionar embebida dentro del LMS Sakai,

por lo que debemos crearla siguiendo las especificaciones del

mismo.

Se han seleccionado los lenguajes de programación Java, JSP y

Javascript porque representan un estándar multiplataforma, y

además, posibilita crear aplicaciones mantenibles con código

reutilizable.

Como herramienta para la subida física de los archivos al

servidor hemos optado por un cliente webDAV, tecnología que

nos ofrece Sakai de forma nativa que nos permite trabajar de

forma independiente a la estructura de archivos o de base de

129

datos del LMS, esto nos permitirá implantar esta solución en

cualquier entorno Sakai, sea cual sea su configuración.


Esta herramienta cubre el campo de la generación de recursos, de

forma que se integra perfectamente con el entorno de Sakai y permite

trabajar con los recursos de forma similar a como lo hace la aplicación

navita, con el añadido de la información semántica.

Por otro lado, ha quedado fuera del desarrollo cierta metainformacion

que Sakai proporciona a sus recursos. La línea futura a seguir consistiría

en agregar dicha información.



esta aplicación.


Los usuarios accederán a una pantalla de identificación donde deben

introducir su contraseña.

Una vez identificados mostraremos un formulario en el que pueden

seleccionar el archivo a subir así como la información semántica que

deseen agregar.

Debemos incluir también formularios para la creación de

topics/TopicItems.

130

6.3.1.3.2 Funciones



RF-1: Añadir nuevos recursos.

RF-2: Añadir nuevos topics.

RF-3: Añadir nuevos topicItems.

RF-4: Identificar al usuario por su contraseña.

RF-5: Listar otros recursos existentes en el sistema.

RF-6: Listar todos los topicItems existentes en el sistema.

RF-7: Listar todos los topics existentes en el sistema.

RF-8: Clasificar topicItems según los topics a los que

pertenecen.

RF-9: Clasificar los recursos según las asignaturas a las que

pertenecen.

RF-10: Relacionar cada recurso con diferentes topicItems.

RF-11: Relacionar cada recurso con otros recursos existentes.

RF-12: Relacionar cada topicItem con un topic concreto.


No se han definido requisitos de rendimiento para el desarrollo de esta

herramienta.



aplicación.

131


El servicio web desarrollado deberá cumplir con las características


Deberá poder instalarse en cualquier entorno Sakai,

independientemente de su configuración.

El sistema deberá poder controlar la introducción de datos no

viables por parte del usuario.

El sistema controlar los credenciales del usuario antes de

permitirle crear nuevos datos.



anterioridad.


ACT-01 Docente

Versión 1.0


Descripción Usuario que crea nuevos datos en el

sistema

Comentarios Deberá ser capaz de crear nuevos

recursos así como asociarlos con


Deberá, del mismo modo, ser capaz de

crear nuevos topics topicItems.

Tabla 28. Definición actor OntoSakai Resources

132


En este apartado se muestra un diagrama de casos de uso (Figura 37)

del funcionamiento de OntoSakai Resources.

Figura 37. . Diagrama de casos de uso OntoSakai Resources

Cabe destacar que, en el caso de CU01, tenemos dos relaciones de

inclusión con los casos de uso CU05 y CU04, esto es debido a que subir

un recurso implica crear las relaciones con los recursos y topicItems que

el docente indique.

Lo mismo sucede con el caso de uso CU03, deben crearse las

relaciones con su topic.

133

En los casos concretos de los listados, se listan los elementos básicos

(recursos o topicItems) y a su vez debemos listar los elementos padre

(Asignaturas y topics) a modo de clasificación de los primeros, facilitando

así la navegación por los listados.

Debido a su extensión, las especificaciones de los casos de uso se

recogen en el "ANEXO A2".








de uso, integrando los casos “include” en los casos que los incluyen.



OntoSakai Resources. El diseño de la solución incluye el diagrama de

clases y el diseño de la interface.


En este apartado veremos el modelo de clases de OntoSakai

Resources.

Esta herramienta cuenta con dos modelos bien diferenciados, por una

parte, la funcionalidad programada en J2EE. Cuya funcionalidad principal

es la de ofrecer información de contexto a través de la API de Sakai.

134

La figura 38 muestra el diagrama de clases de la aplicación.

Figura 38. Diagrama de clases OntoSakai Resources

Como podemos ver, las clases son las siguientes:

MainController: Es la clase de la capa de presentación,

encargada de interactuar directamente con el contexto de Sakai.

SakaiProxy: Es un interfaz que permite obtener datos del

contexto actual de Sakai.

SakaiProxyImp: Implementación de la interfaz SakaiProxy.

ProjectLogic: En esta clase debemos programar las funciones

relacionadas con la lógica de negocio.

Item: Hace referencia a la unidad mínima en Sakai, un ítem

puede representar cualquier objeto en Sakai, como un usuario,

una propertie, etc.

Logger: Es la clase encargada de generar los registros de

sucesos.

135

Por otro lado, las funcionalidades programadas en el lado del cliente,

estas son las encargadas de generar el layout de la aplicación y de

capturar los eventos producidos por el usuario.

La figura 39 muestra el diagrama de componentes de las

funcionalidades en el cliente.

Figura 39. Diagrama de componentes OntoSakai Resources

Como podemos observar, en este caso contamos con 8 componentes.

OntoClient: Encargado de las funciones principales

relacionadas con OntoSakaiWS.

CommonClient: Contiene funciones axuliares así como algunas

de las funciones encargadas del layout.

TopicCreator: Encargado de la gestión de los topic/topicItems.

UploadClient: Funciones relacionadas con la creación de

nuevas instancias y la subida del recurso al servidor

WebDav: Encargado de subir el documento a Sakai.

SubjectIntegrityChecker: Tiene como principal funcionalidad

mantener la integridad referencial en la ontología, comprobando

si los datos son válidos antes de cada inserción.

ListManager: Su principal función es la gestión de los listados

de topics y recursos.

136

Index.jsp: Es la página principal desde la que se gestiona todo

el proceso.

6.3.2.2 Diseño de la interface.

En este apartado se observará el diseño de la interfaz, así como cada

una de sus funcionalidades.

6.3.2.2.1 Pantalla de login

En la siguiente figura 40 podemos observar la interface de acceso a la

herramienta, en ella, el usuario debe introducir su contraseña para poder

continuar.

Figura 40. Diseño Interface OntoSakai Resources: Login

Se solicita solo la contraseña, obteniendo la ID del usuario desde el

contexto, con el fin de limitar el prejuicio que supone para el usuario tener

que loguearse estando ya dentro del LMS Sakai.

6.3.2.2.2 Pantalla general OntoResources

Una vez que el usuario ha accedido al sistema, se encuentra con una

interface para la subida de datos. En la figura 41 se muestra una vista

general de la aplicación, que iremos desglosando en apartados

posteriores.

137

Figura 41. Diseño Interface OntoSakai Resources: General

En primer lugar nos encontramos con un elemento de tipo File, que nos

permite seleccionar el archivo que deseamos subir, el cual se muestra en

el formulario una vez ha sido seleccionado, como muestra la figura 42.

Figura 42. Diseño Interface OntoSakai Resources: Subida

En la parte media de la pantalla, en el lado izquierdo, encontramos la

interface de selección de topicItems, mediante esta interface, el usuario

puede ligar el recurso que va a subir con los diferentes topicItems

existentes en el sistema. En la figura 43 se muestra un recurso

relacionado con tres topicItems.

138

Figura 43. Diseño Interface OntoSakai Resources: Topics Relacionados

Cabe destacar también los dos botones que podemos ver en la parte

inferior izquierda de la imagen. Estos botones nos permiten crear un

nuevo topic o bien un nuevo topicItem, tal y como se muestra a

continuación.

Nuevo Topic; para la creación de un nuevo topic, basta con introducir

su nombre en el formulario que muestra la figura 44.

Figura 44. Diseño Interface OntoSakai Resources: Nuevo Topic

139

Nuevo topicItem; en este caso, debe seleccionarse el topic al cual

pertenecerá el nuevo topicItem que vamos a crear, tal como muestra la

figura 45.

Figura 45. Diseño Interface OntoSakai Resources: Nuevo TopicItem

Finalmente, como podemos ver en la figura 46, encontramos el apartado

de “Recursos relacionados”, desde aquí, el usuario puede relacionar

directamente el nuevo recurso a subir con los recursos que ya existían

previamente en el sistema.

Figura 46. Diseño Interface OntoSakai Resources: Recursos relacionados

140

6.3.3 Pruebas unitarias

Para el caso de la herramienta OntoSakai Resources, se han

planificado pruebas para cada uno de los casos de uso, de forma que

tengamos la certeza de que, en cualquier caso, su funcionamiento es el

esperado. La tabla 29 muestra las pruebas unitarias planificadas.


uso

Propósito Superada

CP-001 Crear nuevo

recurso

CU-01

Creación de

nuevo

recurso

Comprobar la

correcta inserción de

un nuevo recurso

Sí

CP-002 Creación de

nuevos topics

CU-02

Crear

nuevo Topic

Comprobar el

correcto


inserción de topics,

Sí

CP-003 Creación de

nuevos

topicItem

CU-03

Crear

TopicItem

Comprobar el

correcto


inserción de

topicItems.

Sí


de recurso con

diferentes

topicItems

CU-04

Relacionar

recurso con

topicItems

Comprobar que la

relación del recurso a

subir se produce

correctamente con los

topicItems deseados.

Sí


de recurso con

diferentes

recursos

CU05

Relacionar

recurso con

recursos

existentes

Comprobar que la

relación del recurso a

subir se produce

correctamente con los

recursos deseados.

Sí


de topicItem con

un topic en

concreto

CU-06

Relacionar

topicItem

con topic

Comprobar que la

relación del topicItem

creado se produce

correctamente con el

Sí

141

topicItem deseado.

CP-007 Listar todos los

recursos

filtrados por

asignatura

CU-08

Listar

recursos

Comprobar el

correcto listado de

todos los recursos

filtrados por

asignatura.

Sí


topicItems

filtrados por

topic

CU10-Listar

topicItems

Comprobar el

correcto listado de

todos los topicItems

filtrados por Topic

Sí

Tabla 29. Casos de prueba OntoSakai Resources

6.3.4 Despliegue

En este apartado vamos a detallar el despliegue de esta herramienta


figura 47.

Figura 47. Diagrama de despliegue OntoSakai Resources

142

6.4 OntoSakai Browser

6.4.1 Especificación de requisitos de software

En este apartado abarcamos la especificación de requisitos de la

herramienta de Sakai Ontosakai Browser.

6.4.1.1 Propósito


restricciones de la herramienta OntoSakai Browser para uso de los






La herramienta a desarrollar se denominará “OntoSakai Browser”. Esta

herramienta proporcionará una interfaz gráfica para la visualización de los

recursos de un sitio concreto (Una asignatura), permitiendo su descarga.

Así mismo, hará recomendaciones basadas en la información

semántica proporcionada por el docente para cada recurso. Las

recomendaciones deben ser de tres tipos: recomendaciones directas,

recomendaciones a través de topicItem, y recomendaciones a través de

topics.

Estos recursos recomendados, podrán ser también descargados por el

usuario de forma sencilla.

143





Docente: hace referencia al personal de la universidad

encargado de subir los recursos.

Alumno: usuario que consumirá los recursos del campus y al

cual están orientados los servicios de recomendación.

Recurso: elemento subido al campus, que contendrá tanto el

documento proporcionado por el docente como la

metainformacion semántica relacionada con el mismo.

Herramienta: referido a las aplicaciones integradas dentro de

Sakai que ofrecen un servicio o funcionalidad.

LMS: sistema de gestión del aprendizaje. Entorno que facilita el

proceso de aprendizaje de los alumnos.

Topic: área de conocimiento compuesta por diversos temas.

TopicItem: elemento que define un tema determinado dentro de

un área de conocimiento especifica.


El documento recoge los requisitos necesarios para el desarrollo de la

herramienta OntoSakai Browser según el estándar "IEEE Recommended

Practice for Software Requirements Specications (IEEE/ANSI 830 -1993).




144



desarrollo.


Con el objetivo de sustituir la aplicación de visualización de recursos

por parte de los alumnos y permitir la recomendación a los mismos de

nuevos recursos se debe desarrollar esta nueva herramienta.

Esta nueva herramienta debe mostrar un listado, en forma de tabla, de

los recursos relacionados con un sitio determinado (el sitio en el que nos

encontremos en cada momento). De cada recurso debemos mostrar sus

recursos relacionados.



desarrollará la herramienta.

a) Todo usuario con privilegios podrá ver y descargar los recursos.

b) La aplicación debe valerse de OntoSakaiWS para gestionar la


c) La aplicación debe permitir la descarga de los documentos

mediante un cliente webDAV conectado con el LMS Sakai.


Las características de los usuarios son las siguientes:

Usuario: Debe poder ver los recursos del sitio, sus relaciones y

descargas nos recursos necesarios. Cabe destacar que este “usuario”

145

genérico puede ser cualquier usuario del LMS Sakai con acceso a esta

herramienta.






La interface de usuario debe ser sencilla e intuitiva.

Se debe permitir la descarga de los recursos y sus recursos

relacionados.




La herramienta debe funcionar embebida dentro del LMS Sakai,

por lo que debemos crearla siguiendo las especificaciones del

mismo.

Se han seleccionado los lenguajes de programación Java, JSP y

Javascript porque representan un estándar multiplataforma, y

además, posibilita crear aplicaciones mantenibles con código

reutilizable.

Como herramienta para la descarga física de los archivos al

servidor hemos optado por un cliente webDAV, tecnología que

nos ofrece Sakai de forma nativa que nos permite trabajar de

forma independiente a la estructura de archivos o de base de

146

datos del LMS, esto nos permitirá implantar esta solución en

cualquier entorno Sakai, sea cual sea su configuración.


No se han definido requisitos futuros para esta herramienta.



esta aplicación.


Los usuarios accederán a una pantalla de identificación donde deben

introducir su contraseña.

Una vez identificados mostraremos un listado con todos los recursos.

Al interactuar con un recurso determinado debemos mostrar sus

recursos relacionados en tres secciones bien diferenciadas:

Relaciones directas: recursos directamente relacionados por el

docente.

Relaciones mediante topicItem: Recursos que se relacionan con

el actual a través de las relaciones ontológicas de sus

topicItems.

Relaciones mediante topic: Todos los recursos relacionados con

los topics a los que, indirectamente, hace referencia nuestro

recurso.

147

6.4.1.3.2 Funciones



RF-1: Mostrar recursos del sitio en curso.

RF-2: Mostrar recursos relacionados con un recurso concreto.

RF-3: Descargar recursos.

RF-4: Descargar recursos relacionados.

RF-5: Deberá gestionar las credenciales del usuario.


No se han definido requisitos de rendimiento para el desarrollo de esta

herramienta.



aplicación.


La herramienta desarrollada deberá cumplir con las características


Deberá poder instalarse en cualquier entorno Sakai,

independientemente de su configuración.

El sistema controlar los credenciales del usuario antes de

permitirle crear nuevos datos.

148



anterioridad.


ACT-01 Usuario

Versión 1.0


Descripción El usuario podrá ver y descargar los

recursos.

Comentarios Deberá ser capaz de visualizar y

descargar tanto los recursos de un sitio

concreto como los recursos

relacionados con un recurso en

particular.

Tabla 30. Definición actor 1 OntoSakai Browser

149


En este apartado se muestra un diagrama de casos de uso (figura 48)

del funcionamiento de OntoSakai Browser.

Figura 48. Diagrama de casos de uso OntoSakai Browser

Cabe destacar que las relaciones existentes entre el caso de uso CU03

y los casos de uso CU05, CU06 y CU07 es una relación de

generalización, esto es así debido a que estos últimos, son casos

específicos de “Visualizar recursos relacionados”.

Debido a su extensión, la totalidad de los casos de uso se recogen en

el "ANEXO A3".






150



de uso.



OntoSakai Browser. El diseño de la solución incluye el diagrama de

clases y el diseño de la interface.


En este apartado veremos el modelo de clases de OntoSakai Browser.

Esta herramienta cuenta con dos modelos bien diferenciados, por una

parte, la funcionalidad programada en J2EE. Cuya funcionalidad principal

es la de ofrecer información de contexto a través de la API de Sakai.

La figura 49 muestra el diagrama de clases de la aplicación.

Figura 49. Diagrama de clases OntoSakai Browser

151

Como podemos ver, las clases son las siguientes:

MainController: Es la clase de la capa de presentación,

encargada de interactuar directamente con el contexto de Sakai.

SakaiProxy: Es un interfaz que permite obtener datos del

contexto actual de Sakai.

SakaiProxyImp: Implementación de la interfaz SakaiProxy.

ProjectLogic: En esta clase debemos programar las funciones

relacionadas con la lógica de negocio.

Item: Hace referencia a la unidad mínima en Sakai, un ítem

puede representar cualquier objeto en Sakai, como un usuario,

una propertie, etc.

Logger: Es la clase encargada de generar los registros de

sucesos.

Por otro lado, las funcionalidades programadas en el lado del cliente,

estas son las encargadas de generar el layout de la aplicación y de

capturar los eventos producidos por el usuario.

La figura 50 muestra el diagrama de componentes de las

funcionalidades en el cliente.

Figura 50. Diagrama de componentes OntoSakai Browser

.

152

Como podemos observar, tenemos 4 componentes:

OntClient: Encargado de todas las funciones relacionadas con

los datos de la ontología.

WebDav: Es un cliente de webDav para permitir la descarga de

los archivos.

WebDavIF: Actúa de intermediaria entre el cliente de webDAV y

el cliente ontológico, de forma que es capaz de combinar los

datos ofrecidos por ambos para generar los enlaces de

descarga.

Index.jsp: Es la página principal desde la que se gestiona todo el proceso.

6.4.2.2 Diseño de la interface

En este apartado se observará el diseño de la interfaz, así como cada

una de sus funcionalidades.

6.4.2.2.1 Pantalla de login

En la figura 51 podemos observar la interface de acceso a la

herramienta, en ella, el usuario debe introducir su contraseña para poder

continuar.

Figura 51. Diseño Interface OntoSakai Browser: Login

Se solicita solo la contraseña, obteniendo la ID del usuario desde el

contexto, con el fin de limitar el prejuicio que supone para el usuario tener

que loguearse estando ya dentro del LMS Sakai.

153

6.4.2.2.2 Pantalla general OntoBrowser

Una vez que el usuario ha accedido al sistema, se encuentra con un

listado de los recursos subidos en el sitio en curso. En la figura 52 se

muestra una vista general de la aplicación, que iremos desglosando en

apartados posteriores.

Figura 52. Diseño Interface OntoSakai Browser: Listado de recursos

Como podemos observar, contamos con una tabla con los recursos

existentes para el sitio en el que nos encontremos y detalles sobre los

mismos.

Además, de cada recurso podemos ver sus recursos relacionados, en

tres categorías, tal y como se detalla en el documento ERS. La figura 53

los muestra los recursos relacionados con el recurso “Portada.png”.

Figura 53. Diseño Interface OntoSakai Browser: Recursos relacionados

154

También mostramos los recursos relacionados a través de la inferencia

de sus topics y topicItems. Como muestran las figuras 54 y 55.

Figura 54. Diseño Interface OntoSakai Browser: Recursos relacionados TopicItems

Figura 55. Diseño Interface OntoSakai Browser: Recursos relacionados Topics

6.4.2.3 Plan de pruebas unitarias

Para el caso de la herramienta OntoSakai Browser, se han planificado

pruebas para cada uno de los casos de uso, de forma que tengamos la

certeza de que, en cualquier caso, su funcionamiento es el esperado. La

tabla 31 muestra las pruebas unitarias planificadas.


uso

Propósito Superada

CP-001 Visualizar todos

los recursos del

sitio en curso

CU-01

Visualizar

recursos

Comprobar la

correcta visualización

de todos los recursos

del sitio.

Sí

CP-002 Descargar

recursos

CU-02

Descargar

recursos

Comprobar la

correcta descarga de

los recursos

Sí

155

existentes en un sitio

concreto.

CP-003 Descargar

recursos

relacionados

CU-04

Descargar

recursos

relacionados

Comprobar la

correcta descarga de

los recursos inferidos

a través de las

relaciones.

Sí


recursos

directamente

relacionados

CU-05

Visualizar

recursos

directamente

relacionados

Comprobar el

correcto listado de los

recursos directamente

relacionados con un

recursos particular

Sí

CP-005 Lista todos los

recursos

relacionados a

través los

topicItem.

CU-06.

Visualizar

recursos

relacionados

a través de

topicItem

Comprobar el


recursos relacionados

obtenidos de la

inferencia de los

topicItems

Sí

CP-006 Lista todos los

recursos

relacionados a

través los topic.

CU-07.

Visualizar

recursos

relacionados

a través de

topic

Comprobar el


recursos relacionados

obtenidos de la

inferencia de los topic

Sí

Tabla 31. Casos de prueba OntoSakai Browser

156

6.4.3 Despliegue

En este apartado vamos a detallar el despliegue de esta herramienta


figura 56.

Figura 56. Diagrama de despliegue OntoBrowser

157

7. PLAN DE PRUEBAS E INTEGRACIÓN

En esta sección trataremos la integración de todos los elementos de

nuestro desarrollo así como las pruebas de integración que se han

realizado para comprobar el correcto funcionamiento del mismo.

7.1 Plan de pruebas

En esta sección detallaremos las pruebas de integración, ya que otros

tipos de pruebas han sido tratados en aparados anteriores

correspondientes a cada desarrollo en particular.

7.1.1 Pruebas de integración

Para las pruebas de integración hemos creado en Sakai un nuevo sitio,

en el que hemos habilitado nuestras herramientas. En ellas hemos

realizado las operaciones básicas de creación y visualización de datos,

comprobando que, en todos los casos, los comportamientos son los

esperados.

ID Descripción Propósito Superada

CP-001 Crear nuevo sitio

(Asignatura y

herramienta) la

primera vez que se

accede

Comprobar que, la primera vez que

accedemos a un nuevo sitio desde

la herramienta de recursos desde

Sakai, se crea correctamente una

instancia de dicha herramienta en la

ontología.

Sí

CP-002 Crear nuevo recurso Comprobar el correcto

funcionamiento de la creación de

nuevos recursos, certificando que

se crea la instancia correspondiente

y las relaciones en la ontología.

Además de comprobar su correcta

inserción en la base de datos.

Sí

CP-003 Crear nuevo topic Comprobar el correcto Sí

158


nuevos topics, certificando que se

crea la instancia correspondiente en

la ontología.

CP-004 Crear nuevo

topicItem

Comprobar el correcto


nuevos topicItems, certificando que

se crea la instancia correspondiente

y las relaciones en la ontología.

Sí

CP-005 Listado de topic y

topicItems

Comprobar que los topics y

topicItems creados se listan

correctamente.

Sí

CP-006 Listado de recursos Comprobar que, dada una

asignatura concreta, se listan todos

los recursos y son descargables por

parte del usuario.

Sí

CP-007 Listado de recursos

relacionados

Comprobar que, dado un recurso

concreto, se listan todos los

recursos relacionados y son

descargables por parte del usuario.

Sí

CP-008 Creación de eventos Comprobar que, con cada nueva

creación, consulta o descarga, se

generan los eventos

correspondientes en la base de

datos de Sakai.

Sí

Tabla 32. Pruebas de integración

159

7.2 Integración de la solución

En este apartado vamos a detallar el proceso de integración de la

solución desarrollada.

La solución consta de cuatro partes bien diferenciadas:

Servicio web OntoSakaiWS: Encargado de toda la gestión del

modelo ontológico OntoSakai.

Servidor de base de datos MySQL: Contiene la base de datos de

Sakai.

Sakai: Es el LMS como tal, dentro de él hemos desplegado las

herramientas desarrolladas.

Cliente: Consiste en un navegador web, desde el cual el cliente

interactuará con nuestras aplicaciones.

En la figura 57 podemos ver el diagrama de despliegue de la solución.

Figura 57. Diagrama de despliegue de la solución

Como puede verse en el diagrama, nosotros hemos optado por un

equipo servidor basado en una solución Windows. En él hemos instalado

un Tomcat como servidor de aplicaciones y MySQL Server como servidor

de bases de datos.

160

En nuestro servidor Tomcat, hemos desplegado el LMS Sakai, nuestro

servicio Web OntoSakaiWS y las herramientas desarrolladas (OntoSakai

Resources y OntoSakai Browser). Como se puede apreciar, ambas

herramientas hacen uso del servicio Web y, a su vez, están integradas

dentro de Sakai.

En cuanto al lado del cliente, cualquier sistema operativo que cuente

con un navegador compatible con HTML5 no debería permitir usar los

productos desarrollados.

Esta es solo una posible solución, podríamos haber optado, para el

caso del servidor, por cualquier otro sistema operativo que soporte

Tomcat, como podría ser una distribución GNU/Linux o incluso Mac OS X

de Apple.

En el caso del cliente de bases de datos, también podríamos haber

optado por otras soluciones como son ORACLE o MariaDB.

Cabe destacar, que, en el caso tanto de OntoSakaiWS como del

servidor de bases de datos, no es necesario que se encuentren en la

misma máquina que Sakai, pueden instalarse en entornos diferentes

siempre y cuando puedan comunicarse a través de la red.

Todos los detalles sobre el proceso de despliegue y los pasos a seguir

para llevarlo a cabo se encuentran en el Anexo C.

161

8. CONCLUSIONES

8.1 Objetivos alcanzados

Al termino del desarrollo de este trabajo fin de grado, podemos afirmar

que hemos cumplido todos los objetivos propuestos al inicio del mismo.

Como logro principal cabe destacar la consecución de la difícil tarea de

integrar un modelo ontológico experimental dentro de un entorno como

Sakai. Sin duda este ha sido el reto más complejo a llevar a cabo.

Se han completado también de forma satisfactoria los dos desarrollos

paralelos que comprendían la creación de herramientas capaces de

explotar la información aportada por OntoSakai.

8.2 Conclusiones del trabajo y personales

En desarrollo del presente trabajo se han visto involucradas diferentes

áreas de trabajo en las que hemos tenido que profundizar para poder

llevar a buen puerto el desarrollo del mismo.

En primer lugar, nos encontramos con una serie de ontologías que,

sobre el papel, componían un modelo ontológico completo y funcional, si

bien hemos tenido que realizar un proceso de análisis y diseño para poder

integrar las diferentes ontologías dentro de un modelo ontológico que

permita modelar todas las parcelas de un LMS y sus procesos asociados.

Ha habido que crear nuevas relaciones y atributos para algunas de las

clases. Si bien, durante la el desarrollo de la carrera se estudiaron los

fundamentos de la web semántica y los modelos ontológicos, hemos

tenido que ahondar mucho más en este área de conocimiento a fin de

poder completar este desarrollo de manera satisfactoria.

En esta misma línea de trabajo, hemos aprendido a utilizar con cierta

soltura el lenguaje de consultas SPARQL, empleado para consultar la

162

ontología, este lenguaje nos ha dado la capacidad de realizar consultas

complejas que de otro modo no habrían sido posibles. SPARQL no había

sido estudiado durante la carrera, de modo que consideramos esto como

un valor ganado con el desarrollo de este proyecto.

A continuación nos encontramos con la necesidad de desarrollar un

servicio Web que ofreciera todo el conocimiento contenido en la ontología

de una forma fácil de acceder y manipular con el fin de proveer de

contenido semántico al LMS. Una vez más, aunque los fundamentos

teóricos fueron estudiados en la carrera, nunca habíamos desarrollado un

servicio web tan complejo, teniendo, además, que trabajar con el

framework Jena, lo cual supuso una dificultad añadida en este caso.

En cuanto al desarrollo de las herramientas para Sakai, la principal

dificultad que nos hemos encontrado ha sido la escasa calidad de la

documentación del proyecto Sakai. Si bien es cierto que existe una

ingente cantidad de documentación que es posible consultar desde la

web, está documentación es, a menudo, obsoleta o errónea. Hemos

podido suplir esto inscribiéndonos en diferentes listas de correo

relacionadas con el desarrollo sobre esta plataforma. En ellas, gracias a

una excelente comunidad de usuarios siempre dispuestos a echar una

mano, hemos resuelto dudas y aprendido los fundamentos para el

desarrollo de herramientas en Sakai.

En síntesis, con este desarrollo hemos conseguido un modelo de

conocimiento estandarizado para representar la información de contexto

de Sakai. Este modelo, además, podría ser fácilmente escalable y ser

portado para su uso en otros LMS y, gracias al proceso de alineación de

ontologías, puede ser integrado con otras ontologías empleadas en el

ámbito educativo con el fin de mejorar aún más los servicios de

recomendación.

163

A nivel personal, cabe destacar, que ha sido un proceso enriquecedor,

ya que hemos aprendido gran cantidad de nuevos conceptos sobre web

semántica y desarrollo de aplicaciones para la misma.

8.3 Vías futuras

Debido a la enorme dimensión que supone adaptar todo un entorno

LMS para su funcionamiento conjunto con un sistema experto, este

proyecto fin de grado se ha centrado tan solo en desarrollar

principalmente una arquitectura que permita crear, en futuros desarrollos,

nuevas herramientas en Sakai que implementen estas funcionalidades.

En nuestro caso, hemos desarrollado dos herramientas, que permiten la

gestión de recursos con contenido semántico.

A tenor de lo mencionado, y puesto que la base del desarrollo

(OntoSakaiWS) se ha construido teniendo en mente la posibilidad de

incluir nuevas funcionalidades y servicios, podemos citar algunos de los

posibles desarrollos futuros con el fin de integrar toda la funcionalidad de

OntoSakai dentro de un entorno LMS.

Una posible línea de aplicación podemos encontrarla en la creación de

nuevas herramientas para Sakai, siguiendo el proceso descrito en este

trabajo fin de grado. Así, podríamos dotar de contenido semántico a las

siguientes áreas del LMS:

Foros de discusión: En este caso, podríamos almacenar la

información de los eventos generados por los usuarios en dichos

foros, los temas nuevos que son creados, los temas

consultados, los temas respondidos. Con el fin de contar con la

información necesaria para catalogar a los usuarios dentro de

diferentes perfiles.

Anuncios: Mediante la semantización de los anuncios dentro

del campus virtual, contaríamos con la posibilidad de obtener

feedback indirecto sobre los receptores de estos anuncios, esto

164

podría sernos de gran utilidad a la hora de verificar el impacto de

los mismos.

Tareas: Semantizando las tareas, podríamos inferir diferentes

aspectos sobre el trabajo realizado por un alumno concreto,

entre ellos cabe destacar la capacidad de trabajo, la efectividad

de dicho trabajo (Ratio calificación/esfuerzo) y la eficiencia del

alumno (Ratio entre el tiempo transcurrido desde que el alumno

acepta la tarea y el momento de la entrega).

Test: En esta área en particular, las aportaciones de un

contenido semántico asociado a cada test y alumno nos da la

posibilidad de perfilar comportamientos y patrones. Como

alumnos que repiten el test hasta la perfección del mismo, o bien

alumnos que podrían estar falseando los resultados del mismo

de algún modo.

Otra posible vía futura a construir sobre la base aportada por el

presente trabajo fin de grado seria la posibilidad de usar reglas para inferir

aspectos relativos a la recomendación o la personalización del entorno del

LMS mediante la generación de perfiles.

Esto podría llevarse a cabo gracias a la incorporación en OntoSakaiWS

de Pellet, un razonador que permite el uso de reglas expertas para la

inferencia de datos desde nuestro modelo ontológico.

Grosso modo podríamos decir que las reglas a definir en este caso se

podrían clasificar en tres grandes grupos:

a) Reglas de recomendación: El objetivo de estas reglas sería el de

ofrecer recomendaciones, tanto a estudiantes como a docentes, de

acuerdo con diferentes indicadores obtenidos del ámbito del

campus virtual.

165

Algunos ejemplos de estas reglas podrían ser:

Recomendación de recursos en caso de suspender un

examen.

Recomendación de recursos por similitud entre ellos.

Recomendación de herramientas basándonos en el nivel de

uso de las mismas.

b) Reglas de generación de perfiles: Estas reglas tienen como objetivo

la asignación de perfiles a los usuarios del LMS de acuerdo con los

eventos que generan mediante el uso normal del campus virtual.

Algunos ejemplos de este tipo de reglas son:

Usuario activo en herramientas colaborativas.

Usuario inactivo en la herramienta de recursos.

c) Reglas hibridas: Las reglas de recomendación, descritas en el

apartado a, pueden redefinirse agregando información de perfilado

para ofrecer una clasificación más adecuada.

Las siguientes reglas son ejemplos de este tipo:

Perfil activo en herramientas colaborativas con elementos

relacionados.

Perfil activo en herramientas colaborativas con evaluaciones

no superadas.

Sería, del mismo modo, interesante integrar todo el contenido

semántico y toda la información contenida en el modelo ontológico al

proceso de evaluación de los alumnos (Mediante una herramienta

complementaria en Sakai) de modo que el docente, mediante una serie

de informes pueda ver las causas que han llevado a un determinado

alumno a obtener una calificación concreta en una evaluación.

166

Como punto culminante, podríamos desarrollar una aplicación para la

gestión de todos los servicios de recomendación y generación de perfiles

de manera centralizada. De modo que los docentes pudieran a acudir a

ella para añadir, modificar o simplemente visualizar la información

semántica contenida en Sakai. Esta herramienta tendría la capacidad de

realizar informes personalizados por el docente así como la utilidad de dar

una perspectiva global de toda la información contenida en el modelo

ontológico.

167

9. BLIBLIOGRAFIA

1. Agut, R. M. (2001). Especificación de Requisitos Software según

el estándar de IEEE 830.

2. Almunia, P. (8 de Mayo de 2015). IEDGE. Obtenido de

http://blog.iedge.eu/tecnologia-sistemas-informacion/desarrollo/pablo-

almunia-ciclo-de-vida-en-el-desarrollo-de-software-segunda-parte/

3. Apache. (2007). Semantic web framework for Java.

4. Barros, H., Silva, A., Costa, E., Bittencourt, I., Holanda, O., &

Sales, L. (2011). Steps, techniques, and technologies for the development

of intelligent applications based on semantic web services: A case study in

e-learning systems. Engineering Applications of Artificial Intelligence.

5. Bhuasiri, W., Xaymoungkhoun, O., Zo, H., Rho, J., & Ciganek, A.

(2012). Critical success factors for e-learning in developing countries: A

comparative analysis between ICT experts and faculty. Computers &

Education, 843-855.

6. Boneu, J. (2010). Plataformas abiertas de e-learning para el

soporte de contenidos educativos abiertos. Revista Universidad y

Sociedad del Conocimiento (RUSC) de la Universidad Oberta de

Catalunya, 36-47.

7. Borjas, V. (8 de Mayo de 2015). profvanessaborjas. Obtenido de

https://profvanessaborjas.wordpress.com/2012/05/10/metodologia-de-

desarrollo-de-software/

8. Box, Ehnebuske, Kakivaya, Layman, Mendelsohn, Nielsen, &

Winer. (2000). Simple object access protocol (SOAP) 1.1.

168

9. Cantabella, Muñoz, A., & Caballero, A. (2013). Ontocompetence:

An ontology model to evaluate competence. AWERProcedia Information

Technology & Computer Science, 411-418.

10. Eclipse. (14 de Mayo de 2015). Eclipse IDE for Java EE

Developers. Obtenido de

https://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-

developers/lunasr2

11. Fields, K., D., Kolb, M. A., & Bayern, S. (2001). Web Development

with Java Server Pages. Manning Publications Co.

12. Foundation, T. A. (10 de Mayo de 2015). Apache Axis. Obtenido

de http://axis.apache.org/

13. Foundation, T. A. (13 de Mayo de 2015). Apache Maven.

Obtenido de https://maven.apache.org/

14. Foundation, T. A. (13 de Mayo de 2015). Apache Tomcat.

Obtenido de http://tomcat.apache.org/

15. G. Engin, B. A. (2014). Rule-based expert systems for supporting

university students. Rule-based expert systems for supporting university

students, 22-31.

16. Gavriushenko, M., Kankaanranta, M., & Neittaanmaki, P. (2015).

Semantically enhanced decision support for learning management

systems. 2015 IEEE international conference on semantic computing

(ICSC),, 298-305.

17. Gennari, J. H. (2003). The evolution of Protégé: an environment

for knowledge-based systems development. International Journal of

Human-computer studies, 89-123.

169

18. Hafidi, M., & Bensebaa, T. (2013). Development of an adaptive

and intelligent tutoring system by expert system. International Journal of

Computer Applications in Technology, 353-365.

19. Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E. D.,

O'Connor, E., & Pfeiffer, S. (2014). HTML5: A vocabulary and associated

APIs for HTML and XHTML. W3C Recommendation.

20. Hwang, J., Chen, Y., Tsai, S., & Tsai, C. (2011). An expert system

for improving web-based problem-solving ability of students. Expert

Systems with Applications, 8664–8672.

21. Johnson, R., Hoeller, J., Donald, K., Sampaleanu, C., & Harrop, R.

(2012). Spring Framework Reference Documentation.

22. jQuery. (12 de Mayo de 2015). Obtenido de https://jquery.com/

23. Klyne, Graham, & Carroll., J. J. (2006). Resource description

framework (RDF): Concepts and abstract syntax.

24. Kurt, S. (2011). The accessibility of university web sites: The case

of turkish universities. Universal Access in the Information Society(1), 101-

110.

25. McFarland, & Sawyer, D. (2012). CSS3: The Missing Manual.

O'Reilly Media, Inc.

26. McGuinness, L., D., & Harmelen, F. V. (2004). OWL web ontology

language overview. W3C recommendation.

27. Microassist. (8 de Mayo de 2015). Microassist. Obtenido de

http://www.microassist.com/custom-e-learning/learning-management-

systems

170

28. Muñoz, A., J. L., Capel, A., Cantabella, M., & Caballero, A. (2015).

OntoSakai: On the optimization of a Learning Management System using

semantics and user profiling. Expert Systems with Applications, 5995–

6007.

29. MySQL. (13 de Mayo de 2015). Obtenido de

https://www.mysql.com/

30. Natek, S., & Zwilling, M. (2014). Student data mining solution

knowledge management system related to higher education institutions.

Expert Systems with Applications, 6400–6407.

31. Oracle. (10 de Mayo de 2015). Java EE at a Glance. Obtenido de

http://www.oracle.com/technetwork/java/javaee/overview/index.html

32. Özyurt, Ö., Özyurt, H., & Baki, A. (2013). Design and development

of an innovative individualized adaptive and intelligent e-learning system

for teachinglearning of probability unit: Details of UZWEBMAT. Expert

Systems with Applications, 2914–2940.

33. project, C. c. (3 de Mayo de 2015). Campus computing survey.

Obtenido de http://www.campuscomputing.net/item/2013-campus-

computing-survey-0

34. Prud’Hommeaux, Eric, & Seaborne., A. (2008). SPARQL query

language for RDF. W3C recommendation .

35. Rahimi, E., Berg, J. v., & Veen, W. (2015). Facilitating student-

driven constructing of learning environments using web 2.0 personal

learning environments. Computers & Education, 235-246.

36. Software, D. (15 de Mayo de 2015). DBVisualizer. Obtenido de

https://www.dbvis.com/

171

37. StripTM, Jorge.villalobos, Takenbot, Scipion, Nukeador, teoli, . . .

Verruckt. (12 de Mayo de 2015). Mozilla Developer Network: JavaScript.

Obtenido de https://developer.mozilla.org/es/docs/Web/JavaScript

38. Sublime Text. (13 de Mayo de 2015). Obtenido de

http://www.sublimetext.com/

39. UM. (8 de Mayo de 2015). Obtenido de

http://ocw.um.es/ingenierias/fundamentos-de-ingenieria-del-

software/material-de-clase-1/capitulo07.pdf

40. WikiPedia. (12 de Mayo de 2015). Web service. Obtenido de

http://en.wikipedia.org/wiki/Web_service

41. Fernández-López, M., Gómez-Pérez, A., & Juristo, N. (1997).

Methontology: from ontological art towards ontological engineering.

42. Petersen, K., Wohlin, C., & Baca, D. (2009). The waterfall model in

large-scale development. In Product-focused software process

improvement (pp. 386-400). Springer Berlin Heidelberg.

43. Boehm, B. W. (1988). A spiral model of software development and

enhancement. Computer, 21(5), 61-72.

44. McConnell, S., & Root, D. (1996). Lifecycle Planning. Rapid

Development: Taming Wild Software Schedules.

172

173

10. ANEXOS

10.1 Anexo A: Casos de uso

10.1.1 Anexo A1: OntoSakaiWS

10.1.1.1 CU01-Crear Asignatura

CU01 Crear Asignatura

Versión 1.0

Autor Alberto Miguel Oliva

Fuentes Definición del sistema

Descripción Se debe poder dar de alta nuevas asignaturas en el sistema en caso de que sea la primera vez que usen una herramienta semantizada.

Precondición La asignatura debe existir dentro del sistema Sakai

Secuencia normal Paso Acción

1 El sistema recibe los datos de la nueva asignatura

2 Los datos son formateados correctamente

3 El sistema realiza la escritura en el modelo ontológico.

Postcondicion La asignatura queda registrada y lista para albergar contenido semántico.

Excepciones Paso Acción

1 El sistema pierde la conexión con el servidor. Se puede realizar de nuevo la operación una vez se haya establecido de nuevo la conexión con el servidor

Frecuencia esperada Media

Urgencia Alta

Estado Validado

Escalabilidad Alta

Comentarios Se debe garantizar la no duplicidad de datos Tabla 33. Caso de uso OntoSakaiWS: CU01

174

10.1.1.2 CU02-Crear Herramienta

CU02 Crear Herramienta

Versión 1.0



Descripción Se debe poder dar de alta nuevas herramientas en el sistema en caso de que sea la primera vez que se usen en el ámbito de una asignatura concreta.

Precondición Debe existir una asignatura dentro del sistema con la que podamos relacionar esta herramienta


1 El sistema recibe los datos de la nueva herramienta



4 El sistema crea la relación de la herramienta con la asignatura indicada

Postcondicion La herramienta queda registrada y lista para albergar contenido semántico.




Urgencia Alta

Estado Validado

Escalabilidad Alta


175

10.1.1.3 CU03-Crear Topic

CU03 Crear Topic

Versión 1.0



Descripción Dar de alta un nuevo topic dentro del modelo ontológico

Precondición --


1 El sistema recibe los datos del nuevo topic



Postcondicion El topic queda registrado en el sistema




Urgencia Alta

Estado Validado

Escalabilidad Alta


176

10.1.1.4 CU04-Crear TopicItem

CU04 Crear TopicItem

Versión 1.0



Descripción Dar de alta un nuevo topicItem dentro del modelo ontológico

Precondición Debe existir un Topic con el que relacionar el TopicItem


1 El sistema recibe los datos del nuevo TopicItem



4 El sistema crea la relación entre el topicItem y el topic indicado.

Postcondicion El topicItem queda registrado en el sistema




Urgencia Alta

Estado Validado

Escalabilidad Alta


177

10.1.1.5 CU05-Crear Recurso

CU05 Crear Recurso

Versión 1.0



Descripción Se debe poder dar de alta nuevos recursos dentro del modelo ontológico

Precondición Debe existir en el sistema una herramienta dentro de cuyo ámbito daremos de alta los recursos


1 El sistema recibe los datos del nuevo recurso



4 El sistema crea la relación del recurso con la herramienta indicada.

Postcondicion El recurso queda registrado en el sistema



Frecuencia esperada Alta

Urgencia Alta

Estado Validado

Escalabilidad Alta


178

10.1.1.6 CU06- Obtener Topics

CU06 Obtener Topics

Versión 1.0



Descripción Devolver un listado de todos los topics existentes en el sistema

Precondición El sistema debe tener topics dados de alta


1 El sistema una petición de solicitud de datos

2 Realiza una lectura del modelo ontológico

3 Los datos son formateados de modo que puedan ser interpretados por el cliente

4 El sistema devuelve los datos formateados.

Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta

Comentarios -- Tabla 38. Caso de uso OntoSakaiWS: CU06

179

10.1.1.7 CU07-Obtener recursos

CU07 Obtener recursos

Versión 1.0



Descripción Devolver un listado de todos los recursos existentes en el sistema

Precondición El sistema debe tener recursos dados de alta






Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


180

10.1.1.8 CU8-Obtener topicItems contenidos en Topic

CU08 Obtener topicItems contenidos en Topic

Versión 1.0



Descripción Devolver un listado de todos los TopicItems contenidos en un Topic concreto

Precondición El sistema debe tener TopicItems dados de alta


1 El sistema una petición de solicitud de datos que contiene un Topic




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


181

10.1.1.9 CU09-Obtener topicItems referidos por un recurso

CU09 Obtener topicItems referidos por un recurso

Versión 1.0



Descripción Devolver un listado de todos los TopicItems relacionados con un recurso



1 El sistema una petición de solicitud de datos que contiene un recurso




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


182

10.1.1.10 CU10-Obtener topic al que pertenece un topicItem

CU10 Obtener topic al que pertenece un topicItem

Versión 1.0



Descripción Devolver el topic al que pertenece un topicItem concreto



1 El sistema una petición de solicitud de datos que contiene un topicItem




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


183

10.1.1.11 CU11-Obtener recursos de una asignatura

CU11 Obtener recursos de una asignatura

Versión 1.0



Descripción Devolver un listado de todos los recursos de una asignatura concreta.

Precondición El sistema debe tener recursos dados de alta


1 El sistema una petición de solicitud de datos que contiene una asignatura




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


184

10.1.1.12 CU12-Obtener nombre asignatura

CU12 Obtener topicItems referidos por un recurso

Versión 1.0



Descripción Devolver el nombre de una asignatura a través de su ID

Precondición --


1 El sistema una petición de solicitud de datos que contiene el ID de una asignatura




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


185

10.1.1.13 CU13-Obtener asignaturas

CU13 Obtener asignaturas

Versión 1.0



Descripción Devolver un listado de todas las asignaturas registradas en el sistema

Precondición Deben existir asignaturas registradas en el sistema






Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


186

10.1.1.14 CU14-Obtener recursos relacionados con un recurso

CU14 Obtener recursos relacionados con un recurso

Versión 1.0



Descripción Devolver un listado de los recursos directamente relacionados con un recurso particular

Precondición El recurso debe tener otros recursos relacionados.


1 El sistema una petición de solicitud de datos que contiene el ID de un recurso.




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


187

10.1.1.15 CU15-Obtener recursos relacionados con topicItem

CU15 Obtener recursos relacionados con topicItem

Versión 1.0



Descripción Devolver un listado de los recursos referidos a un topicItem en particular

Precondición Debe existir el topicItem y tener recursos relacionados con este.


1 El sistema una petición de solicitud de datos que contiene el topicItem




Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


188

10.1.1.16 CU16-Crear relación consistsOf

CU16 Comprobar existencia de recurso

Versión 1.0



Descripción Crear la relación consistsOf entre topic y topicItem

Precondición Los elementos a relacionar deben existir previamente en el sistema


1 El sistema recibe un topic y un topicItem

2 Genera la relación entre ambos

3 Escribe en el modelo ontológico.

Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


189

10.1.1.17 CU17-Crear relación refersTo

CU17 Crear relación refersTo

Versión 1.0



Descripción Crear la relación refersTo entre ToolElement y topicItem



1 El sistema recibe un ToolElement y un topicItem



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


190

10.1.1.18 CU18-Crear relación isRelatedTo

CU18 Crear relación isRelatedTo

Versión 1.0



Descripción Crear la relación isRelatedTo entre dos ToolElement



1 El sistema recibe los ID de dos ToolElement



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


191

10.1.1.19 CU19-Crear relación belongsTo

CU19 Crear relación belongsTo

Versión 1.0



Descripción Crear la relación belongsTo entre ToolElement y Tool



1 El sistema recibe los ID de ToolElement y de Tool



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


192

10.1.2 Anexo A2: OntoSakai Resources

10.1.2.1 CU01-Crear nuevo recurso

CU01 Crear un nuevo recurso

Versión 1.0



Descripción Crear un nuevo recurso en el sistema

Precondición El usuario debe estar identificado antes de poder crear nuevo contenido.


1 El usuario selecciona el archivo a subir

2 El sistema crea una instancia del recurso dentro de la ontología

3 El sistema sube el archivo al servidor de Sakai y crea una entrada en la base de datos de Sakai

4 El sistema devuelve un mensaje confirmando la subida del archivo.

Postcondicion --


1 La subida no puede realizarse.

2 El sistema muestra un mensaje de error alertando al usuario.


Urgencia Alta

Estado Validado

Escalabilidad Alta

Comentarios -- Tabla 52. Caso de uso OntoSakai Resources: CU01

193

10.1.2.2 CU02-Crear nuevo topic

CU02 Crear un nuevo topic

Versión 1.0



Descripción Crear un nuevo topic en el sistema



1 El usuario introduce la información del topic que desea subir

2 El sistema crea una instancia del topic dentro de la ontología

3 El sistema devuelve un mensaje confirmando la creación del nuevo topic.

Postcondicion --


1 La creación no puede realizarse.



Urgencia Alta

Estado Validado

Escalabilidad Alta


194

10.1.2.3 CU03-Crear nuevo topicItem

CU03 Crear un nuevo topicItem

Versión 1.0



Descripción Crear un nuevo topicItem en el sistema



1 El usuario introduce la información del topicItem que desea subir

2 El sistema crea una instancia del topicItem dentro de la ontología

3 El sistema devuelve un mensaje confirmando la creación del nuevo topic.

Postcondicion --


1 La creación no puede realizarse.



Urgencia Alta

Estado Validado

Escalabilidad Alta


195

10.1.2.4 CU04-Relacionar recurso con topicItem

CU04 Relacionar recurso con topicItem

Versión 1.0



Descripción Relacionar el recursos a subir con topicItems



1 El usuario seleccionara de la lista los topicItems deseados

2 El sistema mostrara los topicItem seleccionados

3 El sistema creará las relaciones mediante el servicio web.

Postcondicion --


1 La relación no puede realizarse.



Urgencia Alta

Estado Validado

Escalabilidad Alta


196

10.1.2.5 CU05-Relacionar recurso con recursos existentes

CU05 Relacionar recurso con topicItem

Versión 1.0



Descripción Relacionar el recursos a subir con otros recursos ya existentes en el sistema



1 El usuario seleccionara de la lista los recursos deseados

2 El sistema mostrara los recursos seleccionados

3 El sistema creará las relaciones mediante el servicio Web.

Postcondicion --





Urgencia Alta

Estado Validado

Escalabilidad Alta


197

10.1.2.6 CU06-Relacionar topicItem con topics

CU06 Relacionar topicItem con topics

Versión 1.0



Descripción Relacionar un nuevo topicItem creado con un topic en particular



1 El usuario seleccionara de la lista el topic deseado

2 Introducirá el nombre del nuevo topicItem

3 El sistema creará las relaciones mediante el servicio Web.

Postcondicion --





Urgencia Alta

Estado Validado

Escalabilidad Alta


198

10.1.2.7 CU07-Listar asignaturas

CU07 Listar asignaturas

Versión 1.0



Descripción Crear un listado de asignaturas y mostrarlas por pantalla.

Precondición El usuario debe estar identificado.


1 Se realiza una petición al servicio Web

2 Se formatean los datos recibidos.

3 Los datos previamente formateados se muestran por pantalla.

Postcondicion --



Urgencia Alta

Estado Validado

Escalabilidad Alta


199

10.1.2.8 Listar recursos

CU08 Listar recursos

Versión 1.0



Descripción Crear un listado de recursos, clasificados por asignatura y mostrarlos por pantalla.






Postcondicion --



Urgencia Alta

Estado Validado

Escalabilidad Alta


200

10.1.2.9 Listar topics

CU09 Listar topics

Versión 1.0



Descripción Crear un listado de topics y mostrarlos por pantalla.






Postcondicion --



Urgencia Alta

Estado Validado

Escalabilidad Alta


201

10.1.2.10 Listar topicItems

CU10 Listar topicItems

Versión 1.0



Descripción Crear un listado de topicItems, clasificados por topics y mostrarlos por pantalla.






Postcondicion --



Urgencia Alta

Estado Validado

Escalabilidad Alta


202

10.1.3 Anexo A3: Ontosakai Browser

10.1.3.1 CU01-Visualizar recursos

CU01 Visualizar recursos

Versión 1.0



Descripción Mostrar los recursos de una asignatura concreta

Precondición El usuario debe estar identificado


1 El sistema realiza una petición de datos enviando la asignatura

2 El sistema recibe y formatea los datos.

3 El sistema muestra una lista con los recursos formateados

Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta

Comentarios -- Tabla 62. Caso de uso OntoSakai Browser: CU01

203

10.1.3.2 CU02-Descargar recursos

CU02 Descargar recursos

Versión 1.0



Descripción Descargar los recursos contenidos en la asignatura

Precondición El usuario debe estar


1 El usuario hace clic sobre el enlace de descarga de uno de los recursos

2 El sistema realiza una petición mediante webDAV y comienza la descarga del archivo

Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


204

10.1.3.3 CU01-Visualizar recursos relacionados

CU03 Visualizar recursos relacionados

Versión 1.0



Descripción Mostrar los recursos relacionados



1 El usuario pulsa sobre el botón de recursos relacionados

1 El sistema realiza una petición de datos.



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


205

10.1.3.4 Descargar recursos relacionados.

CU04 Descargar recursos relacionados

Versión 1.0



Descripción Descargar los recursos relacionados



1 El usuario hace clic sobre el enlace de descarga de uno de los recursos

2 El sistema realiza una petición mediante webDAV y comienza la descarga del archivo

Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


206

10.1.3.5 CU05-Visualizar recursos directamente relacionados

CU05 Visualizar recursos directamente relacionados

Versión 1.0



Descripción Mostrar los recursos directamente relacionados




1 El sistema realiza una petición de datos, enviando el ID del recurso concreto.



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


207

10.1.3.6 CU06-Visualizar relacionados a través de topicItem.

CU06 Visualizar relacionados a través de topicItem

Versión 1.0



Descripción Mostrar los recursos relacionados con el recurso actual por medio de los topicItem




1 El sistema realiza una petición de datos, enviando los topicItem relacionados.



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


208

10.1.3.7 CU07-Visualizar relacionados a través de topic.

CU07 Visualizar relacionados a través de topic

Versión 1.0



Descripción Mostrar los recursos relacionados con el recurso actual por medio de los topic




1 El sistema realiza una petición de datos, enviando los topic relacionados.



Postcondicion --




Urgencia Alta

Estado Validado

Escalabilidad Alta


209

10.2 Anexo B: Diagramas de secuencia

A continuación se describe el modelo de comportamiento a través de

diagramas de secuencia por cada caso de uso del sistema, que muestran

la forma en la que los objetos se relacionan entre sí a lo largo del tiempo.

10.2.1 Anexo B1: OntoSakaiWS

10.2.1.1 CU01- Crear asignatura

Figura 58. Diagrama secuencia OntoSakaiWS: CU01

210

10.2.1.2 CU02- Crear herramienta


10.2.1.3 CU03- Crear Topic


.

211

10.2.1.4 CU04- Crear TopicItem


10.2.1.5 CU05- Crear Recurso


212

10.2.1.6 CU06- Obtener Topics


213

10.2.1.7 CU07- Obtener recursos


10.2.1.8 CU08- Obtener TopicItems contenidos en Topic


214

10.2.1.9 CU09- Obtener TopicItems referidos a un recurso


10.2.1.10 CU10- Obtener Topic al que pertenece un TopicItem


215

10.2.1.11 CU11- Obtener Recursos de una asignatura


10.2.1.12 CU12- Obtener nombre de una asignatura


216

10.2.1.13 CU13- Obtener Asignaturas


10.2.1.14 CU14- Obtener recursos relacionados con recurso


217

10.2.1.15 CU15- Obtener recursos relacionados con topicItem


10.2.1.16 CU16- Crear relación consistsOf


218

10.2.1.17 CU17- Crear relación refersTo


10.2.1.18 CU18- Crear relación isRelatedTo


219

10.2.1.19 CU19- Crear relación belongsTo


220

10.2.2 Anexo B2: OntoSakai Resources

10.2.2.1 CU01- Crear nuevo recurso

Figura 77. Diagrama secuencia OntoSakai Resources: CU01

221

10.2.2.2 CU02- Crear nuevo topic


222

10.2.2.3 CU03- Crear nuevo topicItem


223

10.2.2.4 CU08- Listar recursos


224

10.2.2.5 CU010- Listar topicItems


225

10.2.3 Anexo B3: OntoSakai Browser

10.2.3.1 CU01- Visualizar recursos

Figura 82. Diagrama secuencia OntoSakai Browser: CU01

226

10.2.3.2 CU02- Descargar recursos


227

10.2.3.3 CU04- Descargar recursos relacionados


228

10.2.3.4 CU05- Visualizar recursos directamente relacionados


229

10.2.3.5 CU06- Visualizar recursos relacionados a través de topicItem


230

10.2.3.6 CU07- Visualizar recursos relacionados a través de topic


231

10.3 Anexo C: Manual de instalación

En este anexo se va a tratar la instalación de la solución desde sus

primeras fases, esto es, partiendo de un sistema operativo limpio (Recién

instalado).

En nuestro caso realizaremos la instalación sobre un sistema operativo

Windows 7 Utilamte Edition.

10.3.1 Instalación LMS Sakai

En este apartado vamos a tratar la instalación de Sakai.

Lo primero que debemos hacer es comprobar la versión de java que

tenemos instalada, para ello, abrimos una consola y escribimos java –

versión.

En caso de que el resultado sea diferente de la mostrada en la figura

94, debemos descargar el JDK de la página oficial.

Figura 88. Comprobación Java

Para la instalación de Sakai 10.X se recomienda Java 1.7, sin embargo

nosotros solo hemos conseguido una instalación satisfactoria de Sakai

instalando la versión 1.7.0_76, en cualquier otro caso no hemos podido

desplegar el LMS.

Para descargar el JDK debemos dirigirnos a

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-

downloads-javase7-521261.html#jdk-7u76-oth-JPR.

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u76-oth-JPR

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u76-oth-JPR

232

Una vez en la página de descarga descargaremos la versión para

Windows x86, tal como se muestra en la figura 95.

Figura 89. Descarga Java

Una vez descargado debemos instalarlo, en nuestro caso y para

tenerlo más a mano, lo instalaremos en C:\opt. Esta carpeta la hemos

creado para instalar aquí todo lo necesario para desplegar la solución, de

modo que lo tengamos todo a mano y sea fácilmente localizable.

Por tanto, como muestra la figura 96, cambiaremos la ruta de

instalación del JDK.

233

Figura 90. Instalación JDK

Una vez se complete la instalación de la JDK, la instalación continua

solicitándonos la ruta en la que queremos instalar el JRE. En este caso

debemos elegir una ruta diferente a la anterior, ya que, instalarlos juntos

puede ocasionar errores. Nosotros recomendamos dejar la ruta por

defecto.

Con la instalación finalizada, debemos crear las siguientes variables de

entorno, en Windows 7, para crear variables de entorno debemos hacer

clic en el menú de inicio, y en Equipo, haciendo clic con el botón derecho,

seleccionaremos la opción Propiedades, tal como muestra la figura 97.

Figura 91. Acceso propiedades del sistema

234

Una vez dentro de la ventana de propiedades debemos seleccionar

configuración avanzada del sistema, tal y como muestra la figura 98.

Figura 92. Propiedades del sistema

Aparecerá entonces una nueva ventana, en la que, en la pestaña

Opciones avanzadas, haremos clic sobre el botón Variables de Entorno.

Como se muestra en la figura 99.

Figura 93. Propiedades avanzadas del sistema

235

Una vez estemos en la interface de Variables de entorno debemos

hacer clic sobre el botón “Nueva…” e insertar la siguiente variable de

entorno:

JAVA_HOME C:\opt\jdk1.7.0_76\

La figura 100 muestra cómo hacerlo correctamente.

Figura 94. Nueva variable de entorno

Después de crearla, debemos añadirla a la variable PATH, al final de

la misma, de la siguiente manera

PATH…; C:\opt\jdk1.7.0_76\bin;

Debemos crear también, del mismo modo, una nueva variable de

entorno, con los siguientes datos:

JAVA_OPTS'-server -Xms512m -Xmx1024m -XX:PermSize=128m -

XX:MaxPermSize=512m -XX:NewSize=192m -XX:MaxNewSize=384m -

Djava.awt.headless=true -Dhttp.agent=Sakai -

Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false -

Dsun.lang.ClassLoader.allowArraySyntax=true'.

236

La variable JAVA_OPTS es necesaria debido a que la configuración

por defecto de la máquina virtual de Java es insuficiente para poder

correr una aplicación de las dimensiones de Sakai, es por ello que

debemos modificar algunos parámetros.

El siguiente paso, es instalar Subversión para poder descargar el

código fuente de Sakai.

Para ello nos dirigimos a la web https://sliksvn.com/download/, y

descargamos la versión del cliente SVN 1.8.13 32 BIT, tal como se

muestra en la figura 101.

Figura 95. Descarga SVN

Una vez descargado, ejecutamos el instalador y, nuevamente,

cambiaremos la ruta de instalación, para que se instale en nuestra

carpeta opt, tal como se muestra en la figura 102.

https://sliksvn.com/download/

237

Figura 96. Instalación SVN

Cuando la instalación se haya completado, debemos crear una variable

de entorno siguiendo los pasos que ya indicamos anteriormente.

Posteriormente la añadiremos al PATH, como ya se ha explicado.

La variable de entorno que debemos crear es:

SUBVERSION_HOME C\opt\Subversion\

El siguiente paso es instalar Apache Maven, que usaremos para

compilar y desplegar tanto Sakai como nuestras herramientas.

Para ello, el primer paso será descargarlo desde

http://maven.apache.org/download.cgi.

Una vez en la web, descargaremos la versión 3.3.3 (Binary zip), como

muestra la figura 103.

http://maven.apache.org/download.cgi

238

Figura 97. Descarga Maven

Una vez descargado, simplemente debemos extraer el contenido del

zip en nuestra ruta habitual, la carpeta opt. Quedándonos la ruta de

Maven como C:\opt\apache-maven-3.3.3.

Una vez más, debemos crear la variable de entorno correspondiente

y agregarla al PATH.

MAVEN_HOMEC:\opt\apache-maven-3.3.3.

En este caso debemos también crear una variable de entorno

adicional:

MAVEN_OPTS '-Xms512m -Xmx1024m -XX:PermSize=256m -

XX:MaxPermSize=512m -Djava.util.Arrays.useLegacyMergeSort=true'

A continuación debemos instalar Apache Tomcat como servidor

de aplicaciones, para la instalación de Sakai 10.X se recomienda instalar

Tomcat 7.

Descargamos Apache Tomcat desde la siguiente dirección

http://tomcat.apache.org/download-70.cgi.

http://tomcat.apache.org/download-70.cgi

239

Descargaremos la versión Core, para la plataforma Windows 32bit,

como muestra la figura 104.

Figura 98. Descarga Tomcat

Una vez descargado, simplemente extraemos el contenido del zip

dentro de la carpeta opt, creamos la variable de entorno correspondiente

y la añadimos al PATH como hemos venido haciendo anteriormente.

CATALINA_HOME C:\opt\apache-tomcat-7.0.62.

Tras haber hecho esto, debemos modificar algunos parámetros dentro

del archivo CATALINA_HOME\catalina.properties.

Añadimos los siguiente a la línea que comienza con

“common.loader=…”.

,${catalina.base}/common/classes/,${catalina.base}/common/lib/*.jar

Añadimos lo siguiente a la linea que comienza con

“shared.loader=…”

${catalina.base}/shared/classes/,${catalina.base}/shared/lib/*.jar

Añadimos lo siguiente a la linea que comienza con

“server.loader=…”

${catalina.base}/server/classes/,${catalina.base}/server/lib/*.jar

240

Figura 99. Catalina Properties

También debemos editar el archivo server.xml, añadiendo al conector

del puerto 8080 el parámetro URIEncoding="UTF-8" tal como se muestra

en la figura 106.

Figura 100. Server Properties

Finalmente, iremos al directorio CATALINA_HOME/bin y crearemos un

fichero llamado setenv.bat con el siguiente contenido.

set JAVA_OPTS=-server -Xmx1028m -XX:MaxPermSize=320m -

Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=fals

e -Djava.awt.headless=true -Dcom.sun.management.jmxremote -

Dsun.lang.ClassLoader.allowArraySyntax=true

241

A continuación vamos a instala el JDBC Connector para permitir a

Tomcat acceder a nuestra base de datos.

Para ello, nos dirigimos a la dirección

http://dev.mysql.com/downloads/connector/j/.

Una vez dentro, descargaremos la versión Platform independent, como

se muestra en la figura 107.

Figura 101. Descarga JDBC

Una vez descargado, descomprimimos el zip y copiamos el archivo

mysql-connector-java-5.1.35-bin.jar a la carpeta CATALINA_HOME/lib.

http://dev.mysql.com/downloads/connector/j/

242

Figura 102. Instalación JDBC

Con esto ya tenemos instalado y configurado nuestro servidor Tomcat.

Por último, debemos instalar MySql, para dar soporte a la base de

datos de Sakai.

Para ello nos dirigimos a la dirección

https://dev.mysql.com/downloads/windows/installer/5.5.html.

Una vez allí descargamos la versión para Windows.

https://dev.mysql.com/downloads/windows/installer/5.5.html

243

Figura 103. Descarga MySQL Server

Una vez descargado, lo ejecutamos para instalar MySQL server,

cuando el instalador nos lo solicite, crearemos una contraseña de

administrador y un nuevo usuario, en nuestro caso, hemos usado los

siguientes datos:

Contraseña DBA: sakai.

Usuario nuevo: sakai.

Contraseña: sakai.

Figura 104. Instalación MySQL Server

244

A continuación, creamos su correspondiente variable de entorno y la

agregamos al PATH.

MYSQL_HOME C:\Program Files\MySQL\MySQL Server 5.5.

Una vez tenemos instalado MySql Server, debemos crear la base de

datos para Sakai.

Para ello, vamos a abrir la consola de MySQL.

Figura 105. Acceso MySQL CommandLIne

En ella, escribiremos las siguientes instrucciones, tal y como muestra la

figura 112.

Figura 106. Creación de la base de datos

MySQL> create database SakaiDB default character set utf8;

245

MySQL> grant all privileges on SakaiDB.* to ‘Sakai’@’localhost’ identified

by ‘sakai’;

MySQL> flush privileges;

MySQL> quit;

Con esto, ya tendríamos todos los prerrequisitos necesarios para la

instalación del LMS Sakai.

Llegados a este punto, debemos descargarnos el código fuente de

Sakai utilizando el cliente SVN que instalamos anteriormente, para ello,

abrimos una consola de comandos de Windows, navegamos hasta

nuestra carpeta opt y escribimos el siguiente comando:

svn co https://source.sakaiproject.org/svn/sakai/tags/sakai-10.4/ sakai-10.4

Con esto, comenzará la descarga del código fuente de la versión 10.4

de Sakai. Este proceso puede demorarse hasta 40 minutos, en función de

la conexión a internet de que dispongamos.

Figura 107. Descarga Sakai

Es importante contar con una conexión a internet estable, nosotros

recomendamos estar conectado mediante cable directamente a la red,

hemos constatado que, haciendo la descarga a través de la red wifi se

producían errores.

Cuando el proceso de descarga finalice, svn nos devolverá el control

de la consola de comandos.

246

Figura 108. Descarga Sakai Completada

En este momento, debemos configurar Sakai para que utilice la base

de datos que hemos creado anteriormente, para ello nos iremos a la ruta

C:\opt\sakai-

10.4\config\conIlutracióntion\bundles\src\bundle\org\sakaiproject\config\bu

ndle y copiaremos el archivo default.sakai.properties. Este archivo

debemos pegarlo renombrado como sakai.properties en una nueva

carpeta que crearemos dentro de CATALINA_HOME, debemos nombrar

esta carpeta como Sakai.

Figura 109. Ubicación Sakai.properties

Abrimos el archivo con un editor de texto y modificamos los parámetros

de conexión con la base de datos. Estos parámetros se encuentran dentro

de la sección DATABASE.

Debemos descomentar algunas líneas y establecer ciertos parámetros

tal como se muestra en la figura 116.

247

Figura 110. Sakai.Properties

Guardamos el archivo y ya estamos listos para desplegar Sakai usando

Maven. Para ello, abrimos de nuevo una consola de comandos de

Windows, navegamos hasta la carpeta /opt/Sakai-10.4 y ejecutamos el

siguiente comando.

mvn clean install sakai:deploy -Dmaven.tomcat.home=C:\opt\ apache-tomcat-

7.0.62 -Dsakai.home=C:\opt\tomcat\sakai -Djava.net.preferIPv4Stack=true

Figura 111. Instalación Sakai

Este proceso tardará unos minutos, una vez finalizado solo nos queda

arrancar Tomcat para comprobar que la instalación se ha producido

correctamente.

Para ello, accedemos a CATALINA_HOME/bin desde la consola de

comandos y ejecutamos el comando startup.bat.

248

Figura 112. Arranque servidor

Cuando finalice el proceso de inicio de Tomcat, abrimos un navegador

y nos dirigimos a http://localhost:8080/portal.

Nos debe aparecer una página similar a la que se muestra en la figura

119.

Figura 113. Pantalla Login Sakai

Llegados a este punto, y después de horas de trabajo, hemos

terminado la instalación de Sakai 10.4. Ya podemos apagar de nuevo el

servidor, ejecutando el comando shutdown.bat desde la consola de

comandos.

http://localhost:8080/portal

249

Figura 114. Apagado Servidor

En los apartados siguientes del manual de instalación, mostraremos

como instalar OntoSakaiWS y las herramientas creadas.

10.3.2 Instalación de OntoSakaiWS

En este apartado vamos a detallar el proceso de instalación de

OntoSakaiWS.

Con este trabajo fin de grado se adjunta un disco con los desarrollos

llevados a cabo, dentro del disco encontramos 3 carpetas, OntoSakaiWS,

OntoSakai Resources y OntoSakai browser.

En este caso, debemos acceder a OntoSakaiWS y copiar el archivo

OntoSakaiWS.war en CATALINA_HOME/webapps, como se muestra en

la figura 121.

Figura 115. Copia OntoSakaiWS.war

Una vez hecho esto, arrancamos el servidor como ya vimos en la

sección anterior.

250

Figura 116. Arranque servidor

Para comprobar que la instalación se ha realizado correctamente,

abrimos un navegador web y nos dirigimos a

http://localhost:8080/OntoSakaiWS/services.

Si aparece la página mostrada por la figura 123 estamos de

enhorabuena, hemos instalado satisfactoriamente OntoSakaiWS en

nuestro sistema.

http://localhost:8080/OntoSakaiWS/services

251

Figura 117. Listado de servicios OntoSakaiWS

Una vez más, apagamos el servidor para poder proseguir con la

instalación de las herramientas desarrolladas.

252

10.3.3 Instalación de OntoSakai Resources y OntoSakai Browser

En esta sección vamos a detallar la instalación de las herramientas

desarrolladas para Sakai. Se ha decidido hacer una sección conjunta

puesto que el proceso de instalación para ambas aplicaciones es similar.

No obstante, se detallará paso a paso el proceso de instalación para cada

una de ellas.

El primer paso es dirigirnos a nuestro CD de contenidos desarrollados y

copiar las carpetas OntoResources y OntoBrowser dentro de nuestra

carpeta de Sakai, en /opt/Sakai-10.4.

Figura 118. Copiado Herramientas

A continuación, desde la consola de comandos, accedemos a

OntoBrowser e introducimos el siguiente comando.

mvn clean install sakai:deploy -Dmaven.tomcat.home=C:\opt\tomcat -

Dsakai.home=C:\opt\tomcat\sakai -Djava.net.preferIPv4Stack=true

Figura 119. Instalación OntoSakai Browser

Repetiremos el mismo proceso para OntoResources.

Figura 120. Instalación OntoSakai Resources

253

En ambos casos nos debe aparecer un resultado similar al mostrado

por la figura 127.

Figura 121. Resultado instalación herramienta

Para comprobar que la instalación se ha llevado a cabo correctamente,

arrancamos nuevamente el servidor.

Figura 122. Inicio Tomcat

Y nos identificamos en Sakai, en nuestro caso con los credenciales por

defecto, es decir admin-admin, una vez dentro debemos crear un nuevo

sitio.

Para crear un nuevo sitio hacemos clic en el botón

situado en la esquina superior derecha, se nos desplegará un nuevo

menú, en el cual debemos pulsar sobre “Nuevo Sitio”, como muestra la

figura 129.

254

Figura 123. Creación nuevo sitio (A)

Nos aparecerá un asistente donde debemos elegir el tipo de sitio a

crear, lo habitual sería crear un sitio de tipo “course”, pero debido a que

no hemos configurado el curso académico solamente podemos crear de

tipo “project”, si bien, para esta demostración cumple perfectamente. Así

pues, seleccionamos “Sitio Project” y hacemos clic sobre continuar.

Figura 124. Creación nuevo sitio (B)

La siguiente pantalla nos pide algunos datos básicos sobre el sitio que

vamos a crear, como el título, una breve descripción, etc. Nosotros hemos

llamado a nuestro sitio DAD (Desarrollo de aplicaciones distribuidas). Una

vez rellenados estos campos, pulsamos sobre el botón “Continuar”.

255

Figura 125. Creación nuevo sitio (C)

A continuación se nos muestra un listado de las herramientas

instaladas en Sakai, seleccionamos las que acabamos de instalar,

OntoBrowser y OntoResources y pulsamos en “Continuar”.

Figura 126. Creación nuevo sitio (D)

Por último, debemos establecer las opciones de visibilidad del sitio.

256

Figura 127. Creación nuevo sitio (E)

Al pulsar sobre “Continuar” nos aparecerá un resumen de las opciones

seleccionadas. Hacemos clic en “Crear Sitio” para finalizar.

Figura 128. Creación nuevo sitio (FINAL)

257

Con esto ya tendríamos nuestro sitio creado, para acceder a él

debemos pulsar , situado en el menú superior.

Una vez dentro del sitio, vemos como, efectivamente, nuestras

herramientas han sido instaladas.

Figura 129. Login OntoSakai Resources

Con esto concluimos el manual de instalación, en el Anexo D,

explicamos con detalle el funcionamiento de nuestras herramientas.

258

10.4 Anexo D: Manual de usuario.

En este apartado vamos a explicar detalladamente el funcionamiento

de OntoSakai Resources y OntoSakai Browser.

Cabe destacar, como información a tener en cuenta previa a la lectura

de este capítulo, los roles que los usuarios pueden tomar en cada una de

las herramientas desarrolladas.

Generador de contenido: Este rol se aplica a los usuarios que

tienen capacidad para crear nuevo contenido en la herramienta.

Consumidor de contenido: Este rol se aplica a los usuarios

que hacen uso de los elementos de una herramienta.

La tabla 69 nos muestra los roles que adquiere cada tipo de

usuario en cada herramienta desarrollada.

OntoSakai Resources OntoSakai Browser

Docente Generador de contenido Consumidor de contenido

Estudiante -- Consumidor de contenido

Tabla 69. Roles de usuario

10.4.1 OntoSakai Resources

Esta herramienta tiene como principal función permitir a los docentes

agregar nuevo contenido al campus virtual.

Lo primero que debemos hacer es ingresar nuestra contraseña de

usuario de Sakai.

259

Figura 130. Login OntoResources

Una vez dentro de la aplicación contamos con una interface que nos

permite subir recursos, relacionando cada recurso con topicItems o

recursos existentes en el sistema que deseemos.

Figura 131. Visión general OntoResources

Para ello, simplemente debemos hacer clic en el botón “Seleccionar

archivo” y elegir el recurso que deseamos subir, tal como muestra la figura

138.

260

Figura 132. Subida de archivo

A continuación, si lo deseamos, podemos relacionar el recurso con los

topicItems, para ello, simplemente debemos dirigirnos a la lista de

topicItems, organizados por sus topics, y pulsar en los deseados,

podemos asignar tantos topicItems como queramos. La figura 139

muestra el área de relación con topicItems.

Figura 133. Listado de topics

Como podemos observar, hemos seleccionado del topic

“Programación” el topicItem “Avanzado” y del topic “Ontologías” el

topicItem “Protege”.

261

Del mismo modo, podemos relacionar nuestro recurso con otros

recursos ya existentes en el campus virtual, para ello, en el área de

recursos relacionados, contamos con un listado de todos los recursos.

Figura 134. Listado de recursos relacionados

Una vez tenemos el recurso seleccionado y sus relaciones

establecidas, solo nos resta pulsar sobre el botón “Subir Recurso” para

finalizar la subida.

Figura 135. Subida completada

262

Como vemos, una vez subido el recurso, el sistema nos muestra un

mensaje informándonos de que la subida se ha producido correctamente.

Desde esta herramienta, podemos también insertar nuevos topics o

nuevos topicItems.

Para insertar un nuevo topic, debemos hacer clic sobre el botón

“+Topic” situado bajo el listado de topics.

Una vez lo pulsemos, nos mostrará una interface en la que debemos

introducir el nombre del nuevo topic y pulsar sobre aceptar, tal como

muestra la figura 142.

Figura 136. Crear nuevo topic

Como vemos, una vez el topic se ha creado, el sistema nos muestra un

mensaje informando de ello.

De forma similar, podemos insertar nuevos topicItems pulsando sobre

el botón “+TopicItem”, nos mostrará un formulario en el cual debemos

263

escoger el topic al que pertenecerá e introducir el nombre del topicItem a

crear.

Una vez creado, el sistema nos informa de que ya existe un nuevo

topicItem.

Figura 137. Crear nuevo TopicItem

Como vemos en la figura 143, tanto el topic “Servicios_web” como el

topicItem SOAP han sido añadidos a nuestro listado de topics,

permitiéndonos relacionarlos con nuevos recursos.

264

Figura 138. Comprobación topic creado

Como podemos observar, tanto el listado de topicItems como el de

recursos relacionados cuentan su parte superior con sendos cuadros de

búsqueda, estos cuadros nos permiten filtrar el contenido para facilitar

una búsqueda en caso de que contemos con numerosos elementos en las

listas.

Figura 139. Filtro de listados

265

10.4.2 OntoSakai Browser

En este aparado detallaremos el funcionamiento de OntoSakai

Browser, la herramienta que hemos creado para la visualización de

archivos y la recomendación de recursos relacionados.

De forma similar a como ocurría en el caso anterior, si no estamos

logeados en el sistema, deberemos introducir nuestra contraseña de

usuario de Sakai.

Figura 140. Login OntoBrowser

Una vez que accedamos a la herramienta nos encontraremos con un

listado de los recursos existentes en esta asignatura, en nuestro caso,

DAD.

Figura 141. Listado de recursos OntoBrowser

En este caso, solo aparece el recurso que acabamos de subir, como

podemos ver, nos muestra información sobre el recurso, así como un

pequeño icono a la izquierda del nombre que nos permite visualizar, con

un primer vistazo, el tipo de archivo de que se trata.

266

Para poder ver los recursos relacionados, simplemente debeos hacer

clic sobre . Veremos cómo se despliega un listado con tres pestañas

en la parte inferior a nuestro recurso.

Figura 142. Pestaña recursos relacionados

Cada una de estas pestañas muestra los recursos relacionados según

el tipo de relación que compartan con el recurso raíz, así nos

encontramos con tres tipos de recursos relacionados.

Recursos relacionados: Estos recursos son los que el docente

marcó como recursos relacionados a la hora de subir el archivo,

es decir, tienen una relación directa con nuestro recurso.

Figura 143. Relaciones directas

TopicItems: Estos recursos provienen de la relación de nuestro

recurso subido con los topicItems seleccionados por el docente

a la hora de crear el recurso en el campus virtual. Como muestra

la siguiente imagen, podemos ver a que topicItem y topic

pertenece cada recurso.

267

Figura 144. Relaciones a través de topicItem

Topics: En este caso, los recursos se infieren de las relaciones

indirectas de nuestro recurso con los topics, a través de sus

topicItems, si bien es cierto que la relación es más indirecta, los

recursos pueden, ser del mismo modo, útiles para el alumno.

Figura 145. Relaciones a través de topic

Finalmente, para descargar cualquier recurso, tanto

perteneciente a una asignatura como relacionado, debemos

hacer clic en el enlace del recurso.

268

Figura 146. Descarga de recurso

10.5 Anexo E: Especificación de Methontology

10.5.1 Principales componentes de modelado:

Methontology propone conceptualizar las ontologías utilizando un

conjunto de representaciones intermedias. Dichas representaciones

permiten modelar los componentes que se describen a continuación.

Conceptos: objetos o entidades, considerados desde un punto

de vista amplio. Los conceptos de una ontología están

normalmente organizados en taxonomías en las cuales se

pueden aplicar mecanismos de herencia.

Relaciones: representan un tipo de asociación entre conceptos

del dominio.

Instancias: se utilizan para representar individuos en la

ontología.

Constantes: valores numéricos que no cambian en un largo

período de tiempo.

Atributos: describen propiedades. Se pueden distinguir dos tipos

de atributos: de instancia y de clase.

Axiomas formales: expresiones lógicas siempre verdaderas que

suelen utilizarse para definir restricciones en la ontología.

Reglas: se utilizan normalmente para inferir conocimientos en la

ontología, tales como valores de atributos, instancias de

relaciones, etc.

269

10.5.2 Tareas definidas por Methontology.

Methontology, define, del mismo modo, una serie de pasos o tareas

que debemos seguir a la hora de modelar una ontología:

Tarea 1: Construir el glosario de términos. En primer lugar, el

desarrollador de la ontología construye un glosario de términos que

incluye todos los términos relevantes del dominio (conceptos, instancias,

atributos, relaciones entre conceptos, etc.), sus descripciones en lenguaje

natural, y sus sinónimos y acrónimos.

Tarea 2: Construir taxonomías de conceptos. Una vez que el

glosario de términos contiene suficientes términos, el desarrollador de la

ontología construye las taxonomías de conceptos que definen su

jerarquía. Para construir taxonomías de conceptos, se seleccionan del

glosario de términos aquellos términos que son conceptos.

Tarea 3: Construir diagramas de relaciones binarias ad hoc. Una

vez construida y evaluada la taxonomía, la actividad de conceptualización

propone construir diagramas de relaciones binarias ad hoc. El objetivo de

este diagrama es establecer las relaciones ad hoc existentes entre

conceptos de la misma o de distintas taxonomías de conceptos.

Tarea 4: Construir el diccionario de conceptos. Una vez que las

taxonomías de conceptos y los diagramas de relaciones binarias ad hoc

han sido generados, el desarrollador de la ontología debe especificar

cuáles son las propiedades que describen cada concepto de la

taxonomía, así como las relaciones identificadas en el diagrama del paso

anterior y las instancias de cada uno de los conceptos. El diccionario de

conceptos contiene todos los conceptos del dominio, sus relaciones, sus

instancias, y sus atributos de clase y de instancia.

Las relaciones especificadas para cada concepto son aquellas en las

que el concepto es el origen de la misma.

270

Tarea 5: Describir las relaciones binarias ad hoc. El objetivo de esta

tarea es describir en detalle todas las relaciones binarias ad hoc

identificadas en el diagrama de relaciones binarias e incluidas en el

diccionario de conceptos. Para cada relación binaria ad hoc, el

desarrollador de la ontología debe especificar su nombre, los nombres de

sus conceptos origen y destino, su cardinalidad y su relación inversa, si

existe.

Tarea 6: Describir los atributos de instancia. El objetivo de esta

tarea es describir en detalle todos los atributos de instancia incluidos en el

diccionario de conceptos. Cada fila de la tabla de atributos de instancia

contiene la descripción detallada de un atributo de instancia.

Por cada atributo de instancia, el desarrollador de la ontología debe

especificar su nombre, el concepto al que pertenece el atributo (los

atributos son locales a los conceptos), su tipo de valor, su rango de

valores (en el caso de atributos numéricos), y sus cardinalidades mínima y

máxima.

Tarea 7: Describir los atributos de clase. El objetivo de esta tarea es

describir en detalle todos los atributos de clase incluidos en el diccionario

de conceptos. Para cada atributo de clase, el desarrollador de la ontología

debe rellenar la siguiente información: nombre del atributo, nombre del

concepto donde el atributo se define, tipo de valor, cardinalidad y

valor(es).

Tarea 8: Describir las constantes. El objetivo de esta tarea es

describir en detalle cada una de las constantes identificadas en el glosario

de términos. Para cada constante, el desarrollador de la ontología debe

especificar su nombre, tipo de valor, valor y unidad de medida en el caso

de constantes numéricas.

Tarea 9: Definir axiomas formales. Para realizar esta tarea, el

desarrollador de ontologías debe identificar los axiomas formales que son

necesarios en la ontología y describirlos de manera precisa. Para cada

271

definición de axioma formal, se propone especificar la siguiente

información: nombre, descripción en lenguaje natural, expresión lógica

que define de manera formal el axioma usando lógica de primer orden, y

los conceptos, atributos y relaciones ad hoc utilizadas en el axioma, así

como las variables utilizadas.

Tarea 10: Definir reglas. De manera similar a la tarea previa, en esta

tarea el desarrollador de la ontología debe identificar en primer lugar qué

reglas se necesitan en la ontología, y entonces describirlas en la tabla de

reglas. Para cada regla, se propone incluir la siguiente información:

nombre, descripción en lenguaje natural, expresión que describe

formalmente la regla, y conceptos, atributos y relaciones ad hoc utilizados

en la regla, así como las variables usadas.

METHONTOLOGY propone especificar las expresiones de las reglas

utilizando el formato si <condiciones> entonces <consecuente>. La parte

izquierda de la regla es una conjunción de condiciones simples, mientras

que la parte derecha es una simple expresión de un valor de la ontología.

Tarea 11: Describir instancias. Una vez que el modelo conceptual de

la ontología ha sido creado, se pueden definir las instancias que aparecen

en el diccionario de conceptos. Para cada instancia se define: su nombre,

el nombre del concepto al que pertenece y los valores de sus atributos de

instancia, si se conocen.

En la figura 153 podemos ver, de forma gráfica, un resumen de las

tareas que componen esta metodología.

272

Figura 147. Tareas que componen Methontology

Documents

Deposito TFG Convocatoria Junio 2015