Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de...

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías

presentada por

Ricardo Estrada Peláez Ing. En Sistemas Computacionales por el Instituto Tecnológico de Veracruz

como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dra. Azucena Montes Rendón

Co-director de Tesis:

Dr. Juan Gabriel González Serna

Jurado:

Dr. Máximo López Sánchez – Presidente Dr. Hugo Estrada Esquivel – Secretario

M.C. Humberto Hernández García – Vocal Dr. Juan Gabriel González Serna– Vocal Suplente

Cuernavaca, Morelos, México. 28 de febrero de 2012

Dedicatoria

A mi hijo por nacer:

Te estamos esperando con los brazos abiertos.

Agradecimientos

Quiero agradecer a mis padres María de los Ángeles Peláez Conde y José de Jesús Estrada

Aguilar† por haberme dado vida, y en especial a mi madre por todo el apoyo que me ha

brindado hasta la fecha.

A mi novia Lourdes Vázquez Coronado por estar conmigo todo este tiempo y soportar la

distancia.

Al CONACYT por el apoyo económico aportado por su sistema de becas, sin el cual

probablemente no hubiera realizado la maestría.

A la Dra. Azucena Montes Rendón y el Dr. Juan Gabriel González Serna por su orientación en

esta tesis, así como por sus clases de ontologías y redes respectivamente, que facilitaron de

buen modo el desarrollo de este trabajo.

A mis revisores el Dr. Hugo Estrada Esquivel, el Dr. Máximo López Sánchez y el M.C.

Humberto Hernández García por sus observaciones e interés por hacer de este el mejor trabajo

posible.

A mis amigos y compañeros de maestría que gracias a su compañía hacían menos pesados los

días, en especial a Felipe A. Román, Everardo Munguía y Nazir O. Molina.

Resumen

Los Servicios Basados en Localización (LBS por sus siglas en inglés) dan al usuario final un

conjunto de servicios empezando por su ubicación geográfica. Estos servicios le ofrecen la

posibilidad a los usuarios o máquinas de encontrar o localizar a otra persona, dispositivo,

vehículo, recurso o servicio sensibles a la ubicación, así como la posibilidad de rastrear su

propia ubicación.

El presente trabajo se enfoca en el subsistema de visualización, en donde surge la necesidad de

realizar, mapas auto descriptibles de las instalaciones de organizaciones, es decir, edificios,

plantas, habitaciones, pasillos, accesos, etc. pertenecientes a una organización, logrando con

esto mapas en los cuales sus elementos contengan información de su composición o

caracterización.

En este trabajo de tesis se propone un conjunto de herramientas de software que darán las

bases para mejorar el subsistema de visualización de un sistema de recomendación contextual,

permitiendo realizar una secuencia de tareas relacionadas a la generación y explotación de

mapas semánticos.

Abstract

Location-based services provide end users with a set of services starting by its geographical

location. This services offer to users or machines the possibility to find or locate another

person, device, vehicle, resource or service sensible to the location, as well as the possibility to

track their own position.

This work is focused in the visualization subsystem, where the need to create self-describing

maps of organization‟s facilities arise, that is; buildings, floors, rooms, corridors, access, etc.

belonging to the organization, achieving with this, maps where its elements contain

information about their composition or characterization.

On this thesis is proposed a set of software tools that will place the foundation to enhance the

visualization subsystem of a contextual recommendation system, by allowing to perform a

sequence of tasks related to the creation and exploitation of semantic maps.

i

Tabla de contenido. Tabla de contenido........................................................................................................................ i

Listado de códigos. .................................................................................................................... iii

Listado de figuras. ..................................................................................................................... iii

Listado de tablas. ........................................................................................................................ vi

Glosario de términos y siglas................................................................................................... viii

Capítulo 1 Introducción. .............................................................................................................. 9

1.1 Introducción. .................................................................................................................... 10

1.2 Antecedentes del proyecto. .............................................................................................. 11

1.3 Descripción del problema. ............................................................................................... 13

1.4 Objetivos. ......................................................................................................................... 14

1.4.1 Objetivo general. ...................................................................................................... 14

1.4.2 Objetivos específicos. ............................................................................................... 14

1.5 Justificación y beneficios del proyecto. ........................................................................... 14

1.6 Alcances y limitaciones. .................................................................................................. 16

1.6.1 Alcances. .................................................................................................................. 16

1.6.2 Limitaciones. ............................................................................................................ 16

1.7 Organización del documento. .......................................................................................... 16

Capítulo 2 Marco teórico ........................................................................................................... 18

2. 1 Ontologías. ...................................................................................................................... 19

2.2 Jena. ................................................................................................................................. 19

2.3 SVG y SVG Tiny. ............................................................................................................ 20

2.4 Android. ........................................................................................................................... 21

2.5 TinyLine SVG. ................................................................................................................ 22

Capítulo 3 Estado del arte .......................................................................................................... 24

3.1 Modelos de representación de espacios. .......................................................................... 25

3.1.1 An ontology for context-aware pervasive computing environments. [Chen 2003] 25

3.1.2 LAIR: Location awareness information representation. [Kottahachchi 2005]......... 27

3.1.3 OntoNav: A semantic indoor navigation system. [Anagnostopoulos 2005] ............ 29

3.1.4 ONALIN: ontology and algorithm for indoor routing. [Dudas 2009] ...................... 31

3.1.5 Semantic Location Modeling for Location Navigation in Mobile Environment. [Hu

2004] .................................................................................................................................. 33

3.2 Técnicas para extender SVG. .......................................................................................... 34

ii

3.2.1 Embedding domain semantics. [Chang 2003] .......................................................... 34

3.2.2 Indoor navigation with SVG. [Schmitt 2005] .......................................................... 38

3.2.3 Techniques for binding scalable vector graphics to associated information. [Mor

2007] .................................................................................................................................. 39

3.3 Análisis comparativo. ...................................................................................................... 40

Capítulo 4 Análisis y diseño. ..................................................................................................... 43

4.1 Análisis. ........................................................................................................................... 44

4.1.1 Ontología de infraestructura. ........................................................................................ 45

4.1.2 Herramienta generadora de croquis. ......................................................................... 57

4.1.3 Módulo de edición automática. ................................................................................ 68

4.1.4 Visualizador SVG. .................................................................................................... 74

4.2 Diseño. ............................................................................................................................. 82

4.2.1 Herramienta generadora de croquis .......................................................................... 82

4.2.2 Módulo de edición automática. ................................................................................ 89

4.2.3 Visualizador SVG. .................................................................................................... 91

Capítulo 5 Implementación. ...................................................................................................... 99

5.1 Herramienta para la generación de croquis. .................................................................. 100

5.2 Módulo de edición automática de croquis. .................................................................... 104

5.3 Visualizador SVG. ......................................................................................................... 105

Capítulo 6 Pruebas ................................................................................................................... 110

Capítulo 7 Conclusiones. ......................................................................................................... 131

7.1 Conclusiones. ................................................................................................................. 132

7.2 Aportaciones. ................................................................................................................. 133

7.3 Trabajos futuros. ............................................................................................................ 133

Referencias. ............................................................................................................................. 135

Anexos ..................................................................................................................................... 139

Anexo A1. Plan de pruebas – PP01 ..................................................................................... 140

Anexo A2. Formato del archivo de recomendaciones XML ............................................... 157

Anexo A3. Formato del archivo SVG ................................................................................. 158

iii

Listado de códigos. Código 3.1 Ejemplo de extensión de atributos SVG [Chang 2003] .......................................... 35

Código 3.2 Ejemplo de extensión de modelo de contenido de SVG [Chang 2003].................. 35

Código 3.3 Ejemplo de enlace a datos desde elementos SVG [Chang 2003] ........................... 37

Código 4. Ejemplo de archivo XML de recomendaciones. ..................................................... 157

Código 5. Ejemplo de archivo SVG. ....................................................................................... 159

Listado de figuras. Figura 1-1 Asociación de ubicaciones a mapa [Arjona 2009] .................................................. 12

Figura 1-2 Comparación de formato vectorial con formato de mapa de bits o raster [IES_EP

2011] .......................................................................................................................................... 13

Figura 1-3 Arquitectura general de la extensión de la plataforma T-Guía ................................ 15

Figura 2-1 Arquitectura general de Android [Android 2011] ................................................... 22

Figura 3-1 Parte central de INO [Anagnostopoulos 2005] ........................................................ 30

Figura 3-2 ONALIN [Dudas 2009] ........................................................................................... 32

Figura 3-3 Ejemplo de jerarquía de ubicaciones y salidas en base a un plano. [Hu 2004] ....... 34

Figura 3-4 Generador de mapas SVG ....................................................................................... 39

Figura 3-5 Representación general del trabajo de la patente [Mor 2007] ................................. 40

Figura 4-1 Esquema de interacción entre los módulos desarrollados. ...................................... 44

Figura 4-2 Diagrama conceptual del enlace de la ontología de infraestructura en la red de

ontologías .................................................................................................................................. 45

Figura 4-3 Casos de uso generales del conjunto de herramientas ............................................. 57

Figura 4-4 Caso de uso 1. Generar croquis ............................................................................... 58

Figura 4-5 Diagrama de actividad del caso de uso 1.1 .............................................................. 59





Figura 4-10 Diagrama de actividad del caso de uso 1.6 ............................................................ 64

iv




Figura 4-14 Diagrama de actividad del caso de uso 1.10 .......................................................... 68

Figura 4-15. Caso de uso 2. Editar croquis automáticamente. .................................................. 69

Figura 4-16. Diagrama de actividad del caso de uso 2.1 ........................................................... 70




Figura 4-20. Caso de uso 3. Visualizar croquis. ........................................................................ 74








Figura 4-28 Diagrama de clases de la Herramienta generadora de croquis .............................. 83

Figura 4-29 Diagrama de secuencia para la carga de croquis ................................................... 84

Figura 4-30 Diagrama de secuencia para la eliminación de croquis ......................................... 85

Figura 4-31 Diagrama de secuencia para la selección de croquis y organización .................... 86

Figura 4-32 Diagrama de secuencia para la asociación de información ................................... 87

Figura 4-33 Diagrama de secuencia para la desasociación de información .............................. 88

Figura 4-34 Diagrama de secuencia para generar croquis ......................................................... 88

Figura 4-35. Diagrama de clases de el módulo de edición automática. .................................... 89

Figura 4-36. Diagrama de secuencia del módulo de edición automática. ................................. 91

Figura 4-37. Diagrama de clases del visualizador de SVG. ...................................................... 93

Figura 4-38. Diagrama de secuencia para la carga del archivo SVG. ....................................... 94

Figura 4-39. Diagrama de secuencia para el zoom in y zoom out............................................. 95

Figura 4-40. Diagrama de secuencia para el panning. ............................................................... 96

v

Figura 4-41. Diagrama de secuencia para el reset. .................................................................... 97

Figura 4-42. Diagrama de secuencia para el cambio de capa del croquis. ................................ 98

Figura 5-1 Interacción entre las herramientas desarrolladas ................................................... 100

Figura 5-2 Pantalla inicial de la aplicación ............................................................................. 101

Figura 5-3 Pantalla principal de la aplicación web (Parte 1) ................................................... 102

Figura 5-4 Pantalla principal de la aplicación web (Parte 2) ................................................... 103

Figura 5-5 Interfaz gráfica del editor automático de croquis .................................................. 104

Figura 5-6. Pantalla inicial del visualizador. ........................................................................... 105

Figura 5-7. Menú inferior del visualizador. ............................................................................. 106

Figura 5-8. Menú oculto del visualizador. ............................................................................... 106

Figura 5-9. Carga del croquis en el visualizador. .................................................................... 106

Figura 5-10. Zoom in y zoom out. ........................................................................................... 107

Figura 5-11. Panning. .............................................................................................................. 107

Figura 5-12. Reset. .................................................................................................................. 108

Figura 5-13. Localización ........................................................................................................ 108

Figura 5-14. Cambio de capas ................................................................................................. 109

Figura 6-1 Imágenes del archivo de pruebas por capas ........................................................... 111

Figura 6-2 Croquis de prueba que cumple con los requisitos del caso de prueba HGC-03-01

................................................................................................................................................. 111

Figura 6-3 Carga de croquis en la aplicación .......................................................................... 113

Figura 6-4 Selección de croquis y organización para trabajo .................................................. 113

Figura 6-5 Asociación de información al primer elemento ..................................................... 114

Figura 6-6 Asociación de información al segundo elemento .................................................. 115

Figura 6-7 Asociación de información al tercer elemento ...................................................... 116

Figura 6-8 Verificación de atributo xlink:href en el primer elemento .................................... 117

Figura 6-9 Verificación de atributo xlink:href en el segundo elemento .................................. 117

Figura 6-10 Verificación de atributo xlink:href en el tercer elemento .................................... 118

Figura 6-11 Verificando correspondencia de información para el primer elemento ............... 119

Figura 6-12 Verificando correspondencia de información para el segundo elemento ............ 119

Figura 6-13 Verificando correspondencia de información para el tercer elemento ................ 120

vi

Figura 6-14 Desasociación de información a un elemento...................................................... 121

Figura 6-15 Asociación de información a un nuevo elemento ................................................ 122

Figura 6-16 Verificación del atributo xlink:href para el primer elemento después de la

reasociación ............................................................................................................................. 123

Figura 6-17 Verificación del atributo xlink:href para el segundo elemento después de la

reasociación ............................................................................................................................. 123

Figura 6-18 Verificación del atributo xlink:href para el tercer y cuarto elemento después de la

reasociación ............................................................................................................................. 124

Figura 6-19. Información existente depués de desasociar información. ................................. 124

Figura 6-20 Archivo de recomendaciones a utilizar ................................................................ 125

Figura 6-21 Información del croquis antes del proceso automático de depuración ................ 126

Figura 6-22 Ejecución del módulo de edición automática ...................................................... 126

Figura 6-23 Información adicional después del proceso de edición automática ..................... 127

Figura 6-24 Código de animación agregado por el proceso de edición automática ............... 127

Figura 6-25 Capas en la interfaz gráfica del visualizador ....................................................... 129

Figura 6-26 Efecto de animación e información del primer elemento .................................... 129

Figura 6-27 Efecto de animación e información del segundo elemento ................................. 130

Listado de tablas. Tabla 2-1. Comparativa de APIs o visualizadores SVG para dispositivos móviles .................. 23

Tabla 3-1 Lista completa de clases y propiedades en COBRA-ONT v0.2 [Chen 2003] .......... 26

Tabla 3-2 Análisis comparativo del estado del arte en modelos de representación de espacios

................................................................................................................................................... 41

Tabla 3-3 Análisis comparativo del estado del arte en técnicas para extender SVG ................ 42

Tabla 4-1 Descripción del caso de uso 1.1. Cargar croquis ...................................................... 58

Tabla 4-2 Descripción del caso de uso 1.2. Eliminar croquis ................................................... 59

Tabla 4-3 Descripción del caso de uso 1.3. Seleccionar croquis y organización ...................... 60

Tabla 4-4 Descripción del caso de uso 1.4. Manipular información. ........................................ 61

Tabla 4-5 Descripción del caso de uso 1.5. Generar croquis .................................................... 62

vii

Tabla 4-6 Descripción del caso de uso 1.6. Cargar organizaciones .......................................... 63

Tabla 4-7 Descripción del caso de uso 1.7. Cargar croquis existentes ...................................... 64

Tabla 4-8 Descripción del caso de uso 1.8. Asociar información ............................................. 65

Tabla 4-9 Descripción del caso de uso 1.9. Desasociar información ........................................ 66

Tabla 4-10 Descripción del caso de uso 1.10. Cargar información de espacios ....................... 67

Tabla 4-11. Descripción del caso de uso 2.1. Recibir solicitud de datos. ................................. 69

Tabla 4-12. Descripción del caso de uso 2.2. Enviar croquis editado. ...................................... 70

Tabla 4-13. Descripción del caso de uso 2.3. Extraer ID de recomendaciones. ........................ 71

Tabla 4-14. Descripción del caso de uso 2.4. Editar croquis en base a IDs. ............................. 72

Tabla 4-15. Descripción del caso de uso 3.1. Cargar croquis. .................................................. 75

Tabla 4-16 Descripción del caso de uso 3.2. Interactuar con croquis ....................................... 76

Tabla 4-17. Descripción del caso de uso 3.3. Zoom in. ............................................................ 77

Tabla 4-18. Descripción del caso de uso 3.4. Zoom out. .......................................................... 77

Tabla 4-19. Descripción del caso de uso 3.5. Panning. ............................................................. 78

Tabla 4-20. Descripción del caso de uso 3.6. Reset .................................................................. 79

Tabla 4-21. Descripción del caso de uso 3.7. Cambiar capa ..................................................... 80

Tabla 4-22. Descripción del caso de uso 3.8. Examinar información del croquis .................... 81

Tabla 6-1 Identificadores seleccionados con su información asociada ................................... 117

Tabla 6-2 Información asociada dentro del croquis ................................................................ 118

Tabla 6-3Información restante después del proceso de edición automática ........................... 128

viii

Glosario de términos y siglas.

Mapa semántico En un contexto geográfico, es una representación gráfica que muestra

ubicaciones y contiene información o situación de sus ubicaciones.

Ontología Es una jerarquía de conceptos con atributos y relaciones que describe un

dominio.

QRCodes Es un sistema para almacenar información en una matriz de puntos o un

código de barras bidimensional.

RFID Identificación por Radiofrecuencia (Radio Frequency Identification por

sus siglas en inglés). Es un sistema de almacenamiento y recuperación

de datos que usa dispositivos denominados etiquetas, transpondedores o

tags RFID. El propósito fundamental de la tecnología RFID es transmitir

la identidad de un objeto (similar a un número de serie único) mediante

ondas de radio.

SVG Gráficos Vectoriales Escalables (Scalable Vector Graphics por sus siglas

en inglés). Es un lenguaje para gráficos de dos dimensiones. Es un

estándar gratuito, abierto e independiente de plataforma basado en XML.

SVG Tiny Gráficos Vectoriales Escalables Pequeño (Scalable Vector Graphics

Tiny por sus siglas en inglés). Es un subconjunto de SVG, manejado

como un perfil para uso en dispositivos móviles.

LBS Servicios basados en localización (Location Based Services por sus

siglas en inglés).

Capítulo 1 Introducción.

Capítulo 1 Introducción

10

1.1 Introducción.

Los Servicios Basados en Localización (LBS por sus siglas en inglés) dan al usuario final un

conjunto de servicios empezando por su ubicación geográfica. Estos servicios le ofrecen la

posibilidad a los usuarios o máquinas de encontrar/localizar a otra persona, máquina, vehículo,

recurso o servicios sensibles a la ubicación, así como la posibilidad de rastrear su propia

ubicación. La mayoría de los LBS incluyen dos grandes acciones: a) obtener la ubicación del

usuario y b) utilizar esta información para proveer un servicio personalizado [GSM

Association 2003]. Dentro del Departamento de Ciencias Computacionales del Centro

Nacional de Investigación y Desarrollo Tecnológico (CENIDET) se realizan diferentes

trabajos de tesis en las líneas de investigación de: Ingeniería de Software, Inteligencia

Artificial y Sistemas Distribuidos. En los últimos años, el área de Sistemas Distribuidos ha

desarrollado proyectos en LBS‟s. Algunos trabajos desarrollados en esta área son: “Gateway

SMS Pull para servicios basados en localización con arquitectura de servicios Web”

[Quiñonez 2008] y “API SMS para el procesamiento de consultas georeferenciadas y no

georeferenciadas” [Ruiz 2007]. Se hace particular énfasis en la tesis denominada “Servicios de

localización conscientes del contexto aplicando perfiles de movilidad y tecnologías de

localización heterogéneas” [Arjona 2009], donde se hace uso de dispositivos móviles para

proporcionar servicios conscientes del contexto; uno de estos servicios es el guiado en

interiores, que hace uso de mapas creados manualmente en el formato de imagen JPG, sobre

ellos se registran puntos de interés que se almacenan en un sistema gestor de base de datos, del

cual el dispositivo móvil extrae la información.

Este trabajo de tesis es continuación del trabajo “Servicios de localización conscientes del

contexto aplicando perfiles de movilidad y tecnologías de localización heterogéneas” [Arjona

2009], con el desarrollo de un proyecto compuesto de tres módulos: a) un servicio de

localización, b) un servicio de recomendación, y c) un servicio de visualización. En este

trabajo de tesis se modeló e implementó una ontología y prototipos para la creación, poblado

y visualización de mapas interactivos en formato SVG, estos mapas contienen información

que describe funcionalmente las instalaciones de una organización, es decir, edificios

multinivel, habitaciones, pasillos, accesos, recursos disponibles en cada área, personas


11

asociadas a las áreas y actividades asociadas a las áreas funcionales, como resultado se

obtienen mapas SVG auto-descriptibles. Al tener los mapas auto-descriptibles se logra que

sean independientes de algún servidor de aplicaciones web o sistema gestor de base de datos

para obtener información de su contenido. Para lograr esto, en el presente trabajo se diseñó e

implementó una ontología, la cual, es el punto de partida para generar los mapas de

instalaciones. En esta ontología se crean instancias con sus respectivos atributos y

características que describen en detalle la infraestructura de la organización, en instalaciones y

tecnología, por ejemplo, aulas, laboratorios, auditorios, cubículos, biblioteca, cafetería, etc.

De igual manera aquí se presenta el diseño y la implementaron de dos prototipos para la

explotación de la información almacenada en la ontología de la infraestructura, permitiendo

asociar a los elementos gráficos de archivo SVG, la información de una determinada instancia

de la ontología y posteriormente realizar la consulta en un dispositivo móvil.

1.2 Antecedentes del proyecto.

Servicios de localización conscientes del contexto aplicando perfiles de movilidad y

tecnologías de localización heterogéneas. [Arjona 2009]

Este trabajo se ubica sobre los servicios conscientes del contexto con localización en interiores

en edificios multinivel, presenta la realización de tareas (creación, cancelación y

cumplimiento) pudiendo asociar algún recurso a ella (mediante etiquetas RFID o QRCodes)

para el recordatorio de las tareas al estar en proximidad del recurso asociado a ella.

Dentro de sus tareas existe la capacidad de guiado, donde se selecciona un punto destino y,

basado en la posición actual del dispositivo se solicita a un servidor una ruta, el servidor

devuelve al dispositivo la ruta a seguir y muestra en pantalla la ubicación actual y el punto a

dirigirse, conforme se van leyendo nuevos sensores o códigos de barras, se va actualizando la

posición del usuario en el mapa hasta llegar al destino.


12

Cuenta con una aplicación web que gestiona la información de tareas, ubicaciones, usuarios y

recursos y una aplicación cliente para celulares basados en Android con las siguientes

características:

Las ubicaciones se denotan a través de tarjetas RFID.

Los valores RFID antes mencionados se guardan en una base de datos.

Los valores se asocian a mapas en imágenes de tipo mapa de bits.

Almacena recursos igualmente mediante RFID y sus datos se almacenan en una base

de datos.

Su relevancia para este trabajo de tesis consiste en retomar la parte del uso de mapas para la

orientación del usuario, buscando no depender de entidades externas como un servidor web

para saber la localización, para lo cual se plantea la incorporación de información adicional al

mapa o croquis que se esté desplegando.

Figura 1-1 Asociación de ubicaciones a mapa [Arjona 2009]


13

1.3 Descripción del problema.

Esta tesis es continuación del trabajo realizado en [Arjona 2009], se centra específicamente en

la optimización de mapas organizacionales, los mapas empleados en la tesis de [Arjona 2009]

son imágenes raster1 en formato JPG, las cuales se asocian a través de una aplicación que a

coordenandas de la imagen la ubicación de etiquetas RFID y QRCodes, estas coordenadas son

almacenadas en una base de datos, cuando el dispositivo lee una etiqueta RFID o decodifica

una imagen QRCodes envía una petición al servidor, como respuesta, el servidor le envía una

imagen JPEG en donde se muestra la ubicación del usuario en el mapa.

Una de las principales desventajas del método de solución de la tesis de [Arjona 2009] es que

utiliza mapas organizacionales en formato raster (JPEG), este formato se deforma cuando se

realizan acercamientos a la imagen, lo cual tiene como resultado una calidad de imagen

degradada debido a que se observan los pixeles que la componen. Otro problema con estos

formatos (JPEG) es que no permiten la incorporación de información contextual que los auto-

describa, esto genera que sea necesario recurrir a la manipulación a nivel de bits o se requiera

el acceso a alguna entidad externa, como una base de datos en el caso de [Arjona 2009],

aunado a esto, el uso sobre dispositivos móviles donde el espacio de visualización es reducido

requiere que las imágenes deban ser pequeñas y por lo tanto estas presentan una degradación

en su calidad si se realizan acercamientos sobre ellas como se aprecia en la Figura 1-2.

Figura 1-2 Comparación de formato vectorial con formato de mapa de bits o raster [IES_EP 2011]

1 Rejilla rectangular de pixeles


14

1.4 Objetivos.

1.4.1 Objetivo general.

Desarrollar un conjunto de herramientas para la generación y explotación de mapas

semánticos, en formato SVG, que describan las instalaciones de organizaciones mediante el

uso de ontologías, estos mapas contendrán información contextual de las instalaciones de una

organización que les permitirá ser auto-descriptibles.

1.4.2 Objetivos específicos.

i. Crear una ontología de estructuras físicas de interiores y exteriores de organizaciones

que represente su caracterización tanto espacial como funcional.

ii. Crear una herramienta que permita generar mapas SVG con anotaciones semánticas

del exterior e interiores de una organización.

iii. Crear un módulo que permita recibir un conjunto de recomendaciones y modificar el

mapa SVG para que represente la información que corresponde a las recomendaciones.

iv. Crear un visualizador de mapas SVG que soporten anotaciones semánticas y trabajen

sobre plataforma Android 2.x en dispositivos móviles.

1.5 Justificación y beneficios del proyecto.

El presente trabajo forma parte de un sistema de recomendación contextual que tiene sus

orígenes en el trabajo desarrollado por “Servicios de localización conscientes del contexto

aplicando perfiles de movilidad y tecnologías de localización heterogéneas” [Arjona 2009] y

que es acompañado de los trabajos “Sistema de recomendación contextual basado en

ontologías para ambientes organizacionales y de usuario en entornos de cómputo móvil”

[González 2012] y “API para servicios de localización basada en tecnología RFID, QRCode,

WiFi y Bluetooth” [Yris 2012], la arquitectura general del proyecto que extiende la plataforma

T-Guía se describe en la Figura 1-3


15

Con esta tesis se mejora y complementa la plataforma T-Guia desarrollada en [Arjona 2009],

específicamente en la parte del subsistema de creación y visualización de mapas mediante el

desarrollo de prototipos que permitan realizar tareas de una manera más eficiente y que

proporcionen nuevas funcionalidades.

El resultado de esta tesis ayudará a:

Contar con un modelo semántico que caracterice y describa la infraestructura de las

organizaciones con el uso de la red de ontologías, que incluye la ontología desarrollada

en esta tesis.

Mejorar el proceso de creación de mapas para el sistema de localización T-Guía.

Contar con mapas de instalaciones organizacionales auto-descriptivos e interactivos

como resultado del uso del formato de imágenes vectoriales SVG.

Generador de mapas

semánticos SVG

Módulo de edición

automática de mapas

Gestor de recomendaciones

contextuales [González

2012]

API de localización

[Yris 2012]

Visualizador

SVG

Evaluador de

recomendaciones

[González 2012]

Repositorio de

mapas

Red de

ontologías

BD Relacional

Figura 1-3 Arquitectura general de la extensión de la plataforma T-Guía


16

1.6 Alcances y limitaciones.

Para el desarrollo de éste proyecto se tomaron las siguientes consideraciones.

1.6.1 Alcances.

Se manipulan mapas en formato SVG y SVG Tiny y se generara mapas en formato

SVG Tiny.

La aplicación para la generación de mapas semánticos es multiplataforma, esto

implementado mediante una aplicación web.

La población de información a elementos en el mapa se hace de forma manual por

parte de un usuario, con la ayuda de la aplicación web.

El módulo de edición automática de información contextual contenida en mapas SVG

sólo se encarga de remover la información que no sea necesaria del mapa.

El visualizador de mapas SVG se implementa sobre la plataforma Android 2.x.

1.6.2 Limitaciones.

No se considera la implementación del prototipo para la creación de mapas SVG, se

utilizarán editores de código abierto para este proceso de creación de los mapas.

1.7 Organización del documento.

La estructura restante del documento se presenta a continuación. El Capítulo 2 Marco teórico,

da un panorama general de las herramientas y plataformas sobre las cuales se basa el

desarrollo de esta tesis. El Capítulo 3 Estado del arte da una recopilación de los artículos más

relevantes que poseen similitudes en ciertos aspectos con el trabajo a desarrollado en esta

tesis, concluyendo el capítulo con una tabla comparativa entre estos trabajos y esta tesis. El

Capítulo 4 Análisis y diseño muestra los diagramas UML correspondientes de ambas etapas

que presentan las conceptualizaciones de las herramientas desarrolladas. El Capítulo 5

Implementación, muestra las interfaces gráficas y funcionalidades de los prototipos

desarrollados. El Capítulo 6 Pruebas, contiene la ejecución de los casos de prueba definidos en


17

el Anexo A1. El Capítulo 7 Conclusiones, describe los resultados obtenidos con este trabajo de

tesis, así como los trabajos futuros.

Posteriormente a esta serie de capítulos se encuentra una secuencia de anexos, donde el Anexo

A1 es el plan de pruebas que se ejecutó sobre los prototipos, el Anexo A2 especifica el

formato que debe tener el archivo de recomendaciones empleado por uno de los prototipos y el

Anexo A3 hace referencia al formato al cual se debe acoplar el mapa SVG para el

funcionamiento adecuado con los prototipos. Por último se encuentra la sección de referencias.

Capítulo 2 Marco teórico


19

La naturaleza de este trabajo de tesis requirió incursionar en diferentes disciplinas entre las

cuales sobresalen: ontologías, imágenes vectoriales, programación para dispositivos móviles y

para la Web. Por ello se destacan en esta sección las tecnologías involucradas.

2. 1 Ontologías.

En el contexto de las ciencias de la computación y la informática, [Gruber 2009] define a una

ontología como un conjunto de primitivas figurativas con las cuales se modela un dominio de

conocimiento o discurso. Las primitivas figurativas son típicamente clases (o conjuntos),

atributos (o propiedades) y relaciones (o relaciones entre miembros de clases). Las

definiciones de las primitivas incluyen información acerca de su significado. En un contexto

de sistemas de base de datos, la ontología se puede ver como un nivel de abstracción de

modelos de datos, análogo a los modelos relacionales y jerárquicos, pero pretendido para

modelar conocimiento acerca de individuos, sus atributos, y sus relaciones con otros

individuos. Las ontologías son normalmente especificadas en lenguajes que permiten separar

lo abstracto de las estructuras de datos e implementación de estrategias; en la práctica, los

lenguajes de ontologías están más cerca en expresividad a la lógica de primer orden que los

lenguajes utilizados para modelar bases de datos. Por esta razón, se dice que las ontologías

están a nivel “semántico”, mientras que los esquemas de base de datos son modelos a un nivel

“físico” o “lógico”. Debido a su independencia de modelos de datos a más bajo nivel, las

ontologías se utilizan para integrar bases de datos heterogéneas, permitir la interoperabilidad

entre sistemas distintos, y especificar interfaces para sistemas independientes basados en

conocimiento.

2.2 Jena.

Jena es un framework en Java para construir aplicaciones para la Web semántica [Jena 2011].

Jena es de código abierto e incluye:

Una API para RDF.

Una API para OWL

Almacenamiento persistente y en memoria


20

Un motor de consultas SPARQL.

Hay dos subsistemas para la persistencia de datos RDF y OWL en Jena, SDB y TDB [Jena2

2011]:

TDB es un motor de persistencia nativo y de alto rendimiento que utiliza

almacenamiento e indexación a la medida.

SDB es una capa de persistencia que utiliza una base de datos SQL y soporta

completamente transacciones ACID.

2.3 SVG y SVG Tiny.

De acuerdo con [SVG 2008], SVG es un lenguaje para describir gráficas de dos dimensiones

en XML. SVG permite tres tipos de objetos gráficos: figuras de gráficos vectoriales (ej. Trazos

que consisten de líneas o curvas), imágenes y texto. Dichos objetos gráficos pueden ser

agrupados, estilizados y transformados; este conjunto de características incluye

transformaciones anidadas, caminos de corte, máscaras alfa, filtros de efectos y plantillas de

objetos.

Los dibujos SVG pueden ser interactivos y dinámicos. Se pueden definir y activar

animaciones ya sea declarativamente (ej. Empotrando elementos de animación SVG en el

contenido de un elemento gráfico SVG) o por medio de scripts.

Se ha establecido por la demanda de la industria, que se requiere de alguna forma de visualizar

gráficas vectoriales en dispositivos pequeños. Para cumplir con estas demandas el grupo de

trabajo de SVG se comprometió a hacer un esfuerzo por crear una especificación para un

perfil que se enfocara a dispositivos móviles.

Sin embargo, su solo perfil no es suficiente para tratar con la variedad de dispositivos móviles,

porque cada dispositivo móvil tiene diferentes características en términos de velocidad de

CPU, tamaño de memoria y soporte de colores. Para atacar el rango de diferentes familias de

dispositivos, dos perfiles fueron definidos. El primer perfil de bajo nivel, SVG Tiny (SVGT)


21

es adecuado para dispositivos móviles altamente restringidos; mientras que el segundo perfil,

SVG Basic (SVGB) está enfocado a dispositivos móviles de mayor nivel.

Para asegurar la interoperabilidad entre contenido y herramientas de software que cumplen

con diferentes perfiles, SVGT está especificado como un subconjunto propio de SVGB, y

SVGB un subconjunto propio de SVG. [SVGM 2003]

Sin embargo, avances en el DOM nivel 3, provocaron que se diera una revisión al uso de

lenguajes de programación en SVG Tiny. También se desarrolló una interfaz ligera

denominada Micro DOM, o uDOM. Con lo anterior se hizo posible el control programático

sobre SVG en todo el rango de plataformas, desde celulares a equipos de escritorio. En

consecuencia, solo existe un perfil móvil para SVG: Svg Tiny 1.2.

2.4 Android.

Android es una plataforma para dispositivos móviles que incluye un sistema operativo,

middleware y aplicaciones clave desarrollado por la Open Handset Alliance, un grupo de

líderes en tecnología y móviles que comparten la visión de cambiar la experiencia móvil de los

consumidores [OPA 2011].

La arquitectura de Android se puede apreciar en la Figura 2-1 y sus partes principales se

describen a continuación:

Aplicaciones. Android se instala con un conjunto básico de aplicaciones todas escritas

en el lenguaje de programación Java.

Framework de aplicaciones. Se provee una plataforma de desarrollo abierta que

permite a los desarrolladores construir aplicaciones innovadoras, teniendo acceso a las

mismas API utilizadas por las aplicaciones básicas de Android.

Librerías. Se incluyen también un conjunto de librerías en C/C++ utilizadas por varios

componentes del sistema Android. Capacidades que también están expuestas a los

desarrolladores mediante el framework de aplicaciones.

Tiempo de ejecución. Android incluye un conjunto de librerías que provee la mayoría

de la funcionalidad de las librerías básicas de Java. También posee la capacidad de

ejecutar múltiples máquinas virtuales de manera eficiente.


22

Kernel de Linux. Android se basa en la versión 2.6 de Linux para el sistema básico de

servicios como la seguridad, administración de memoria y procesos, la pila de red, etc.

Figura 2-1 Arquitectura general de Android [Android 2011]

2.5 TinyLine SVG.

TinyLine SVG implementa un motor de SVG Tiny 1.1 y superior para la plataforma Java y

Android. [TinyLine 2011]. Sus principales características son: motor SVG Tiny 1.1 y superior,

soporta fuentes SVG, imágenes raster, caminos y elementos texto, soporta animaciones SMIL

y eventos, permite flujos en texto y comprimidos gzip, posee un código compacto (JAR de

100KB aproximadamente) y una API con una pequeña curva de aprendizaje.

Esta API es la empleada para el desarrollo de uno de los prototipos y fue elegida en base a la

comparación de sus características con otros opciones que trabajan con SVG, siendo esta la

que proporciona mayores ventajas, como se observa en la Tabla 2-1.


23

Tabla 2-1. Comparativa de APIs o visualizadores SVG para dispositivos móviles

Opción Ventajas Desventajas

Anti-Grain Geometry

Código abierto.

Código nativo (C++). Soporte básico de SVG. Visualizador solamente.

libsvg-android Código abierto.

Código nativo (Lenguaje C). Solo funciona con imágenes estáticas. Visualizador solamente.

svg4mobile Código abierto en Java.

Visualizador solamente. Implementa una porción reducida de la especificación SVG Tiny 1.1

TinyLine SVG Código para Java. Soporta SVG Tiny 1.1+. Permite alterar el DOM de SVG. Posee una API

Código cerrado. De paga.

Capítulo 3 Estado del arte


25

Para este trabajo fue necesario recurrir a diferentes áreas de las ciencias computacionales,

destacando la ingeniería ontológica y las imágenes vectoriales. Por ello, el estado del arte se

divide en dos grandes secciones, los trabajos que involucran el aspecto relacionado al

modelado de espacios mediante el uso de ontologías y la segunda sección, los trabajos que

involucran técnicas para extender el formato SVG que permitan contener información

adicional a la provista por el estándar.

3.1 Modelos de representación de espacios.

3.1.1 An ontology for context-aware pervasive computing environments. [Chen 2003]

Descripción.

En este trabajo se presenta a CoBrA (Context Broker Architecture), una arquitectura

mediadora de agentes para apoyar a los sistemas conscientes del contexto en espacios

inteligentes. El rol de esta arquitectura es mantener un modelo compartido del contexto para

una comunidad de agentes y dispositivos en un espacio, protegiendo la privacidad de los

usuarios aplicando políticas definidas por los usuarios para compartir información con otros

agentes en el espacio asociado.

Características.

Utiliza un conjunto un conjunto de ontologías denominado COBRA-ONT, que le

ayuda a CoBrA a compartir el conocimiento del contexto con otros agentes y le

permiten razonar acerca del contexto, el cual se categoriza en cuatro temas:

1. Lugares físicos.

2. Agentes (humanos o software).

3. Contexto de localización de los agentes.

4. Contexto de actividades de los agentes.

No menciona el uso de mapas dentro de su sistema, solamente el uso de la información

espacial descrita en la ontología para realizar inferencias.

La conceptualización de espacios va desde un Campus a una habitación

Ontologías expresadas en OWL.


26

Tabla 3-1 Lista completa de clases y propiedades en COBRA-ONT v0.2 [Chen 2003]

Relevancia para la tesis.

Es de particular interés la definición de la clase Place (lugar) y dos subclases de Place (que

representa la abstracción de una ubicación física), AtomicPlace (lugar atómico) y

CompoundPlace (lugar compuesto). La propiedad de contención está representada por

spatiallySubsumes (contiene espacialmente) y isSpatiallySubsumedBy (está espacialmente

contenido por). Existen subclases predefinidas de AtomicPlace tales como, Room (habitación),

Hallway (pasillo), Stairway (escalera) y ParkingLot (estacionamiento), y subclases

predefinidas de CompoundPlace como Campus y Building (Edificio).

Sin embargo, la categorización de los conceptos anteriores se basa en un tipo de aplicaciones

conscientes del contexto que necesitan basarse en el prototipo CoBrA (como lo es la ubicación

de agentes y políticas de seguridad). Por tanto para una aplicación consciente del contexto con

un enfoque diferente es necesario modificar la jerarquía de la ontología para poder reutilizarla.


27

3.1.2 LAIR: Location awareness information representation. [Kottahachchi 2005]

Descripción.

Este artículo se enfoca a la necesidad de un modelo de espacios que represente no solo dónde

está una persona, sino también de qué lugares está cerca y que puede hacer en esos lugares

cercanos. Pretende dejar a un lado los modelos hechos a la medida y propone una

representación universal de ubicaciones, que pueda ser utilizada sin pensar en una aplicación

específica, para construir aplicaciones basadas en dicho modelo.

Características.

El modelo representa tanto exteriores como interiores.

El modelo puede representar las características funcionales de los espacios así como

recursos.

Se pretende que la ontología esté disponible en DAML, OWL y RDF.

Dado que solamente se propone un modelo; el uso de mapas, su formato e

implementación es dependiente de la aplicación a crear.


LAIR es una ontología inspirada en el modelo TOUR de Kuiper [Kuipers 1977] de los mapas

cognitivos de una persona acerca de los espacios a gran escala, utiliza los siguientes

conceptos:

Entity: colección de Resources que representan al mundo real Person, Place, etc.

Resource: artículo o servicio dentro del control de una Entity en particular.

Security Manager: software contenido en cada Entity para administrar su seguridad, tal como

control de acceso.

Derivado de los conceptos básicos, se definen los siguientes subconceptos:

Place: Entity utilizado para representar un lugar del mundo real. En general contiene las

siguientes propiedades:

Name: forma de referirse al Place.


28

On: lista de Paths sobre los que está este Place.

Star: lista de tripletas (Path, heading, dirección de Path), que describe la geometría de la

intersección formada por los Paths, que se encuentran en este Place, el valor de heading va de

0 a 360.

View: lista de tripletas (Place, orientación, distancia) que describe los otros Place que pueden

ser vistos desde este.

Contained: lista desordenada de Places.

Function: lista de Functional Places que describe que puede hacerse y para que se usa este

Place.

AbnormalActions: modifica la lista de acciones heredada de Funcional Place.

Resources: describe los servicios e ítems disponibles en este lugar. Heredado de Entity.

Occupants: propiedad dinámica que lista las entidades Person que ocupan actualmente el

lugar.

Path: enlazan Places. Se puede viajar en dirección +1 o -1 (+, - son direcciones arbitrarias).

Sus propiedades son:

Name: Una forma de referirse a este Path.

Row: Una lista de listas ordenadas de Places. Cada lista es una secuencia de Places

encontrados cuando se va por el Path en dirección +1.

Functional Place: Describen aquellas Actions que pueden hacerse en un espacio dado. Tiene

las siguientes propiedades:

Name: forma de referirse a este Functional Place.

Supports: lista de Actions que pueden realizarse en este lugar.

Action: tarea que puede realizarse en un espacio dado usando los Resources disponibles.

Contienen las siguientes propiedades.

Name: forma de referirse a esta acción.

Requires: lista de Resources requeridos para realizar la acción.


29

Utility: función que describa la utilidad ganada por el Place cuando esta acción se lleva a

cabo.

Cost: función que describa el costo incurrido por el lugar al realizarse la acción.

Person: Entity representando una persona del mundo real. Hereda de Entity una lista de

Resources en el control de esta persona. Tiene las siguientes propiedades:

Name: forma de referirse a esta persona.

Location: lugar donde esta persona está actualmente.

Interests: lista de Actions que describen los intereses de esta persona.

Del modelo anterior podemos extraer algunos conceptos y propiedades generales que pueden

ayudar a describir la infraestructura del edificio, como lo son el FunctionalPlace y Action, así

como observar que pueden no ser necesarios subconceptos de Place como se propone en

[Chen 2003]

3.1.3 OntoNav: A semantic indoor navigation system. [Anagnostopoulos 2005]

Descripción.

OntoNav es un sistema de navegación en ambientes interiores basado en un modelo híbrido

(geométrico y semántico) de éstos ambientes. OntoNav está centrado en el usuario en el

sentido que las rutas y las guías que las describen son dadas dependiendo de las capacidades

perceptivas o físicas del usuario, así como sus preferencias particulares. Para este trabajo

desarrollaron INO (Indoor Navigation Ontology), que se adecua a las tareas de presentación y

búsqueda de rutas. Una parte central de la ontología se muestra en la Figura 3-1.


30

Figura 3-1 Parte central de INO [Anagnostopoulos 2005]

Características.

El modelo presentado limita su capacidad de representación a interiores de edificios.

Se utiliza una base de datos espacial para calcular las rutas.

La ontología sirve para rutas en base a preferencias o perfiles de usuario.

Se devuelve un conjunto de instrucciones y no un mapa de la ruta.


INO es nuestro punto de interés dado que es el modelo encargado de representar los caminos y

ubicaciones:

User: representa los usuarios del servicio de navegación.

PointOfInterest: cualquier ubicación física o virtual u objeto que le resulte de interés al

usuario.

Passage: cualquier elemento espacial parte de un Path y que tiene propiedades de

accesibilidad específicas. Se pueden caracterizar en horizontales (conectan corredores en el

mismo piso) y verticales (conectan corredores de diferentes pisos). Los cruces son un tipo

especial de passage que conectan uno o más corredores o fuerzan al cambio de dirección del

usuario o indican el inicio o fin de corredores.

Exit: una entrada o salida de una región interior, La región puede ser todo el edificio, una

planta o un cuarto.


31

Obstacle: cualquier cosa que impida el paso del usuario.

CorridorSegment: concepto creado para facilitar el modelado, conecta exits con passages.

Corridor: compuesto de segmentos de corredor, el cual conecta dos cruces o un passage

vertical con un cruce.

Anchor: cualquier passage, exit, o pointofinterest en un path que pueda ayudar a la

presentación del plan de navegación.

Path: una secuencia intercalada de corridors, exits y passages, que es capaz de llevar a un

usuario de su ubicación a su destino.

El autor considera que los conceptos anteriores son insuficientes, por ello importan de otras

ontologías espaciales conceptos como habitación, planta, edificio. Sin embargo de este trabajo

podemos utilizar el concepto de salida que es importante en la definición de la infraestructura

de un edificio.

3.1.4 ONALIN: ontology and algorithm for indoor routing. [Dudas 2009]

Descripción.

Aquí se presenta una ontología y un algoritmo para encontrar rutas en interiores para

diferentes tipos de usuarios (personas con discapacidades físicas, cognitivas o sensoriales)

basándose en los estándares ADA (American Disability Act) [ADA 1994], entre otros

requerimientos.

Características.

La conceptualización de espacios se enfoca solamente a interiores.

Acceso al sistema a través de internet vía un cliente web o un dispositivo móvil con

acceso a internet.

No menciona si el resultado es un mapa con la ruta visible o un conjunto de

direcciones.


32

Utiliza un servidor web para contener la ontología, una estructura que modela los

pasillos y sus conexiones, el BIM2 y un módulo para calcular rutas.

Figura 3-2 ONALIN [Dudas 2009]


Para cumplir con los estándares ADA se incluyen información como la altura de una escalera,

disponibilidad de un pasamanos, el ancho de los pasillos, inclinación de rampas o corredores,

varios conjuntos de datos para sanitarios, señalamientos permanentes que por su lectura

ayuden al usuario o Braille, de lo cual se pueden rescatar para nuestro trabajo algunas

propiedades necesarias para la descripción de las capacidades de la infraestructura a modelar.

De igual manera que en [Anagnostopoulos 2005] podemos observar la incidencia en el

concepto de salida.

2 BIM (Building Information Modeling). Es la última generación de OOCAD (Object Oriented Computer-Aided

Design, Diseño Asistido por Computadora Orientado a Objetos) en el cual todos los objetos del edificio son capturados en un solo “proyecto de base de datos” o “edificio virtual”.


33

3.1.5 Semantic Location Modeling for Location Navigation in Mobile Environment. [Hu

2004]

Descripción.

Los autores nos presentan un modelo de ubicación semántica que conserva la semántica de la

topología y la distancia para apoyar a la navegación en interiores esto para facilitar el

mantenimiento y la construcción programática del modelo. Dicho modelo tiene la visión de

permitir al usuario mirar, navegar o buscar una ubicación física en interiores u otros ambientes

restringidos.

Características.

Conceptualización del modelo para interiores o espacios restringidos.

Uso para navegar en interiores y búsqueda de ruta más corta.

Utilización de grafos para representar el modelo.

La población del modelo puede ser manual o automática (técnicas de reconocimiento

de lugares de un plano de plantas).

Presenta una jerarquía de ubicaciones y salidas.


En la metodología que propone este trabajo es definido un concepto de “ubicación” que

menciona que “la ubicación de una entidad es un área geográfica limitada con una o más

„salidas‟, donde una „salida‟ es un punto límite desde el cual una entidad puede ser accedida”.

El trabajo utiliza las salidas para crear una jerarquía de estas y así buscar rutas de navegación.

Para nuestro trabajo tomamos la asociación de ubicación-salida para establecer solamente una

relación espacial entre ubicaciones de modo que se defina el número de salidas de cada

ubicación.


34

Figura 3-3 Ejemplo de jerarquía de ubicaciones y salidas en base a un plano. [Hu 2004]

3.2 Técnicas para extender SVG.

3.2.1 Embedding domain semantics. [Chang 2003]

Descripción.

Este trabajo presenta tres enfoques para asociar datos de otros dominios a elementos gráficos

de SVG, haciendo énfasis en producir documentos SVG que sean desplegables por un

visualizador SVG convencional.

Características.

Presenta métodos para agregar información a un archivo SVG sin perder sus

capacidades de visualización.

Son métodos de propósito general, por tanto su uso depende de la aplicación a

desarrollar.

El SVG resultante no necesariamente es un mapa.

No utiliza recursos externos para la información asociada a los mapas.


De este trabajo podemos obtener formas de estructurar el documento SVG para agregarles

información adicional a la que provee la especificación por omisión. Nos presenta los

siguientes 3 métodos:


35

a) Agregar nuevos atributos a los elementos de SVG.

Teniendo de ejemplo a un polígono que represente a un pueblo o ciudad, podría desearse tener

asociados su área y perímetro en el mapa. Una forma directa de lograrlo es extendiendo los

atributos del tipo polígono con su área y perímetro, de manera que cada información pueda ser

asociada a cada elemento polígono como un atributo.

Código 3.1 Ejemplo de extensión de atributos SVG [Chang 2003]

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"

"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [

<!ATTLIST polygon

area CDATA #IMPLIED

circumference CDATA #IMPLIED>

]>

<svg width="100" height="100" viewBox="0 0 100 100"

xmlns="http://www.w3.org/2000/svg">

<defs>

<style type="text/css"><![CDATA[

polygon { fill: green;

stroke: black;

stroke-width: 1}

]]>

</style>

</defs>

<polygon id="_10001001" points="10,10 10,90 90,90 90,10"

area="6400" circumference="320"/>

</svg>

La ventaja de este enfoque es que la relación entre el elemento SVG y los datos de dominio es

bastante clara. La desventaja es que solo datos de tipo simple pueden ser introducidos para los

atributos y no permite la incorporación de información de dominio de tipo estructurado.

b) Extender los modelos de contenido de los elementos de SVG.

Aquí se extiende el modelo del elemento SVG permitiendo que se tengan hijos de tipo canton

del nombre de espacios m, que tiene a su vez hijos con los datos relacionados al dominio de un

pueblo o ciudad: nombre, estadística, límites (el límite expresado por un elemento geométrico

de SVG).

Código 3.2 Ejemplo de extensión de modelo de contenido de SVG [Chang 2003]




<!ATTLIST svg

xmlns:m CDATA #IMPLIED>

Información adicional

mediante la extensión

de atributos

Uso de los

atributos

definidos


36

<!ENTITY % svgExt "| m:canton">

<!ELEMENT m:canton (m:name*, m:statistics, m:boundary)>

<!ATTLIST m:canton

id ID #REQUIRED

bndtype (village | county) #REQUIRED>

<!ELEMENT m:name EMPTY>

<!ATTLIST m:name

lang (chinese | tonyonPinyin) "chinese"

desc CDATA #REQUIRED>

<!ELEMENT m:statistics (m:population)>

<!ELEMENT m:population EMPTY>

<!ATTLIST m:population

count CDATA #REQUIRED>

<!ELEMENT m:boundary ((g | path| polygon | polyline |

rect | circle | ellipse | line)*, m:geometricInfo)>

<!ELEMENT m:geometricInfo EMPTY>

<!ATTLIST m:geometricInfo

area CDATA #IMPLIED

circumference CDATA #IMPLIED>

]>

<svg width="100" height="100" viewBox="0 0 100 100"

xmlns="http://www.w3.org/2000/svg"

xmlns:m="http://example.tsm.iis.sinica.edu.tw">

<defs>

<style type="text/css"><![CDATA[

polygon { fill: green;

stroke: black;

stroke-width: 1}

]]>

</style>

</defs>

<m:canton id="_10001001" bndtype="village">

<m:name lang="tonyonPinyin" desc="myvillage"/>

<m:statistics>

<m:population count="100"/>

</m:statistics>

<m:boundary>

<polygon id="_pg01" points="10,10 10,90 90,90 90,10"/>

<m:geometricInfo area="6400" circumference="320"/>

</m:boundary>

</m:canton>

</svg>

Las ventajas con respecto al enfoque anterior es que se puede utilizar un vocabulario ajeno del

dominio de SVG, la relación entre los elementos geométricos de SVG y sus anotaciones

semánticas es clara y no es muy difícil extraer los elementos núcleo de SVG para formar un

documento renderizable3.

La desventaja principal de este enfoque es que el SVG resultante solo será reconocido por

algunos de los visualizadores SVG.

3 El renderizado es el proceso de generar una imagen desde un modelo.

Información adicional

mediante la extensión

del modelo SVG.

Integración de un

elemento externo a SVG.


37

c) Enlazar a datos de un dominio específico desde elementos de SVG.

Este enfoque es una mezcla de los dos anteriores, en este caso se extiende el elemento defs de

SVG para incorporar los datos del dominio y a través del atributo xlink:href en la figura

geométrica se apunta a la información adicional declarar en los defs.

Código 3.3 Ejemplo de enlace a datos desde elementos SVG [Chang 2003]




....

<!ENTITY % defsExt "| tsm:cantons">

<!ELEMENT tsm:cantons (tsm:canton)*>

<!ELEMENT tsm:canton (tsm:countyName, tsm:townName,

tsm:countyNamePinyin, tsm:townNamePinyin, tsm:area,

tsm:population, tsm:statistics)*>

....

<!ELEMENT tsm:statistics (tsm:Han | tsm:Paiwan | tsm:Bunun |

tsm:Puyuma | tsm:Amis | tsm:Atayal | tsm:Rukai |

tsm:Tsou | tsm:Tau | tsm:Others | tsm:Saisiat)*>

<!ELEMENT tsm:Han EMPTY>

<!ATTLIST tsm:Han

count CDATA #REQUIRED>

....

]>

<svg viewBox="0 0 260618 377029" xmlns="http://www.w3.org/2000/svg"

xmlns:tsm="http://example.tsm.iis.sinica.edu.tw"

xmlns:xlink="http://www.w3.org/1999/xlink">

<defs>

....

<tsm:canton id="infoOf_1000801">

<tsm:countyNamePinyin>Nantou County</tsm:countyNamePinyin>

<tsm:townNamePinyin>Nantou City</tsm:townNamePinyin>

<tsm:area>71.6008</tsm:area>

<tsm:population>97469</tsm:population>

<tsm:statistics desc="Population of Ethnic Groups">

<tsm:Han count="96921"/>

<tsm:Paiwan count="45"/>

<tsm:Bunun count="216"/>

<tsm:Puyuma count="13"/>

<tsm:Amis count="113"/>

<tsm:Atayal count="94"/>

<tsm:Rukai count="12"/>

<tsm:Others count="11"/>

<tsm:Tsou count="27"/>

<tsm:Tau count="14"/>

<tsm:Saisiat count="3"/>

</tsm:statistics>

</tsm:canton>

....

</defs>

....

Se define

información

adicional dentro de

la etiqueta <defs>


38

<path centroidX="126307.837425" centroidY="152741.66092"

class="normalBoundary" d="M126434,149343L131895,149725 .... "

id="_1000801" xlink:href="#infoOf_1000801"/>

....

</svg>

3.2.2 Indoor navigation with SVG. [Schmitt 2005]

Descripción

El trabajo describe una guía móvil para proveer ayuda de navegación en interiores a los

visitantes de un edificio de oficina.

Características.

El trabajo está limitado a interiores de edificios de oficina.

Se hace uso del formato SVG para los croquis de los interiores.

No hace uso de ontologías

Se hace uso de XSLT para pasar de XML a SVG


En el trabajo se desarrollaron un conjunto de herramientas de ayuda para la guía móvil, de la

cual es de interés el componente de generación de mapas SVG.

Para cumplir el propósito del trabajo, desarrollaron un DTD especial modelando conceptos

comunes como habitaciones de diferente forma y función (oficina, cocina, etc.), puertas,

accesos, objetos especiales como extintores, entre otros. Para facilitar la creación de mapas de

plantas se creó un editor a la medida en Java. Este editor permite definir nuevos objetos de

planta y previsualizar la salida en SVG. Se tienen hojas de estilo XSLT para las diferentes

configuraciones y se emplean para convertir el archivo XML en un plano de habitaciones en la

versión de SVG deseada.

Se enlaza a la información mediante

el atributo xlink:href


39

Figura 3-4 Generador de mapas SVG

3.2.3 Techniques for binding scalable vector graphics to associated information. [Mor

2007]

Descripción.

Esta patente presenta una técnica para proveer información adicional relacionada a un objeto

de SVG a través de una interfaz gráfica. Las sentencias SVG están ligadas con un apuntador

hacia un recurso que incluye información que le pertenece al objeto. El apuntador del recurso

asociado a una sentencia SVG, puede ser extraído del documento. La información es retirada

del recurso en base al apuntador.

Características.

Método de propósito general para incorporar y obtener información adicional de un

elemento de SVG.

Utiliza recursos externos para la información adicional.


40

Figura 3-5 Representación general del trabajo de la patente [Mor 2007]


A pesar de emplear recursos externos para contener la información adicional a los elementos

propios de SVG, en este trabajo se pueden notar el uso del método (c) descrito en [Chang

2003] y por tanto considerarlo como una de las mejores formas de agregar datos de otro

dominio a un documento SVG.

3.3 Análisis comparativo.

En la Tabla 3-2 se presenta el análisis comparativo de los trabajos descritos en el estado del

arte referentes a los modelos de representación de espacios, se definen 4 características de

relevancia para la comparación:

1. Granularidad de la representación de espacios. Se utiliza para observar el alcance

que se tiene en cuanto a qué espacios pueden ser representados dentro de cada trabajo.

2. Representación de objetos adicionales a espacios. Esto es, si la representación

modela por default o mediante el uso de otros recursos alguna otra característica que

no sea un espacio.


41

3. Tecnología de la representación. Define en dónde es plasmada la información

relacionada con los espacios.

4. Uso de la representación de espacios. Esta característica indica para que se emplea la

representación de espacios dentro del trabajo.

Dentro de los valores para las características se encuentra el valor “Dependiente de la

aplicación” esto se da debido a que los trabajos para los cuales el valor aplica son trabajos

sobre los cuales no necesariamente se utilizan para representación de espacios y mapas y por

tanto quedan a disposición de quien desarrolle la manera de implementar.

Tabla 3-2 Análisis comparativo del estado del arte en modelos de representación de espacios

Granularidad

de la

representación

de espacios

Representación

de objetos

adicionales a

espacios

Tecnología de

la

representación

Uso de la

representación

de espacios

Chen 2003 De Campus a

habitación

Agentes y

actividades

mediante

ontologías

adicionales

OWL Realizar

inferencias sobre

el contexto

Hu 2004 Plantas y

habitaciones

Ninguna Grafos Navegación en

interiores y

búsqueda de

camino más

corto

Anagnostopoulos

2005

Plantas y

habitaciones

No menciona Base de datos

espacial y OWL

Hacer

inferencias para

seleccionar la

mejor ruta de un

conjunto de rutas

en base a perfil

del usuario

Kottahachchi

2005

De países a

habitaciones

Funciones,

actividades,

recursos,

personas de

forma nativa

DAML, OWL y

RDF

Modelo general

para apoyar a

aplicaciones

conscientes del

contexto

Dudas 2009 Plantas y Objetos que Ontología, Proveer la mejor


42

habitaciones representen

obstáculos

modelo de

redes de

pasillos y BIM

ruta en base a

perfil del usuario

Tesis De países a

habitaciones

Funciones,

actividades y

recursos para

enlace con

ontologías

externas

OWL Acotado a la

descripción de la

infraestructura

de

organizaciones

En la Tabla 3-3 se presenta el análisis comparativo de los trabajos descritos en el estado del

arte referentes a la extensión del formato SVG para contener información adicional a lo

establecido en el estándar, se definen la técnica empleada, así como sus puntos a favor y en

contra.

Tabla 3-3 Análisis comparativo del estado del arte en técnicas para extender SVG

Técnica Pros Contras

Chang

2003 (a)

Agregar atributos a los

elementos SVG

Propósito general,

Claridad de la relación

elemento-información.

No permite información

estructurada.

Chang

2003 (b)

Extender los modelos

de los elementos SVG

Propósito general.



Permite información

estructurada.

Puede no ser reconocido el

formato por algunos visores.

Chang

2003 (c)

Enlazar a datos desde

elementos SVG

Propósito general.



Permite información

estructurada.

El desarrollo de la DTD puede

volverse complejo dependiendo

de la información que se quiera

incluir

Schmitt

2005

Conversión a SVG de

datos en XML

mediante DTD y

XSLT

No menciona. Limitado a un vocabulario de

oficina

Mor

2007

Enlazar a datos desde

elementos SVG

Propósito general. El enlace se realiza a entidades

externas que proveen la

información.

Tesis Enlazar a datos desde

elementos SVG

Propósito general.

No requiere DTD.

Información

estructurada.

Capítulo 4 Análisis y diseño.

Capítulo 4 Análisis y diseño

44

4.1 Análisis.

El presente trabajo de tesis se conforma del desarrollo de un conjunto de herramientas que

permiten: a) agregar información a un mapa SVG de manera manual asociando a las figuras

del mapa información de la organización, b) recibir un conjunto de recomendaciones que

permiten modificar de manera automática el mapa SVG, extrayendo información que no está

considerada en las recomendaciones, este proceso lo denominamos destilado del mapa SVG,

para denotar de manera gráfica los puntos de interés y eliminar información que no es

pertinente a las recomendaciones de entrada y c) hacer uso del mapa SVG y explorar su

información dentro de un dispositivo móvil que funcione con la plataforma Android 2.x.

También incluyó el desarrollo de una ontología para la representación de infraestructura que

funge como fuente de datos para los prototipos software y que además es parte de una red de

ontologías, donde es complemento para proveer una descripción más amplia de una

organización.

La Figura 4-2 muestra de manera sencilla como una ubicación (infraestructura de una

organización) puede relacionarse con conceptos de otras ontologías como lo son personas (que

utilizan el espacio) y recursos (que son propios del lugar). La ontología de infraestructura

Repositorio de ontologías existentes

Módulo de

generación de

mapas SVG con

anotaciones

semánticas

Repositorio de

mapas SVG

Módulo de

edición

automática de

mapas SVG

Visualizador

SVG

Ontología de infraestructura

Figura 4-1 Esquema de interacción entre los módulos desarrollados.


45

complementa la red de ontologías y a la vez funciona como un puente de comunicación entre

los datos ya registrados en la red de ontologías mediante la relación de los conceptos

existentes con los definidos en la infraestructura.

Figura 4-2 Diagrama conceptual del enlace de la ontología de infraestructura en la red de ontologías

4.1.1 Ontología de infraestructura.

4.1.1.1 Metodología para crear la ontología.

Nos basamos en dos trabajos respecto a creación de ontologías para llevar a cabo la tarea de

desarrollo de la ontología de infraestructura necesaria para la tesis: “Guía Para Crear Tu

Primera Ontología” [Noy 2005] y “METHONTOLOGY” [Fernández 1997]:

[Noy 2005] propone los siguientes pasos:

1. Determinar el dominio y alcance de la ontología, con ayuda de preguntas básicas

como:


46

a. ¿Cuál es el dominio que cubrirá la ontología?

b. ¿Para qué usaremos la ontología?

c. ¿A qué tipos de preguntas deberá proveer respuestas la información en la

ontología?

2. Considerar la reutilización de ontologías existentes. Verificar si podemos refinar y

extender recursos existentes para nuestro dominio y tarea particular.

3. Enumerar términos importantes para la ontología. Escribir una lista con todos los

términos con los que quisiéramos hacer enunciados o dar explicación a un usuario.

4. Definir las clases y la jerarquía de clases.

5. Definir las propiedades de las clases (denominados en esta metodología “slots”).

6. Definir las facetas de los slots. (Cardinalidad, tipo de valor, dominio y rango).

7. Crear instancias.

[Noy 2005] da un panorama general, por lo que se complementan las etapas y plantillas con el

trabajo de [Fernández 1997], la cual propone las siguientes tareas [Gómez 2004]:

1. Construir un glosario de términos que identifique el conjunto de términos que serán

incluidos en la ontología, su definición en lenguaje natural, y sus sinónimos y

acrónimos.

2. Construir una taxonomía de conceptos para clasificar conceptos.

3. Construir diagramas de relaciones binarias para identificar relaciones entre conceptos

de la ontología.

4. Construir el diccionario de conceptos, que contiene principalmente instancias de

conceptos para cada concepto, atributos de clases y sus relaciones.

5. Describir a detalle cada relación binaria que parece en los diagramas y el diccionario

de conceptos.

6. Describir a detalle cada atributo de instancia que aparece en el diccionario de

conceptos.

7. Describir a detalle cada atributo de clase que aparece en el diccionario de conceptos.

8. Describir a detalle cada constante y producir una tabla de constantes

9. Describir axiomas formales.


47

10. Describir reglas.

Opcionalmente, introducir información de instancias.

4.1.1.2 Definición de dominio y alcances de la ontología.

La ontología debe cubrir los conceptos y relaciones inherentes a la descripción de ubicaciones

(espacios físicos) que puedan existir dentro del perímetro de los terrenos de organizaciones.

El uso de la ontología es para representar funciones y recursos asociados a los elementos de

mapas de interiores y exteriores de la infraestructura de una organización.

Se pueden atacar preguntas que traten con la ubicación de espacios y con las capacidades de

estos, como pueden ser: ¿En qué edificio está el laboratorio x, la oficina y, o el aula z?,

¿Cuántas personas pueden estar en el auditorio de la organización?, ¿Quién es la persona que

ocupa esta área?, etc.

4.1.1.3 Ontologías existentes.

Dentro del reporte del estado del arte se localizaron algunas ontologías que no tratan

precisamente de modelar la infraestructura pero si los espacios, por lo tanto se utilizaron

algunos de sus conceptos y relaciones como base para nuestra ontología. Para observar lo

relevante de esos trabajos referirse al reporte del estado del arte.

4.1.1.4 Conceptos extraídos de las ontologías existentes.

Door [Dudas 2009]

AutomaticDoor [Dudas 2009]

EmergencyDoor [Dudas 2009]

ManualDoor [Dudas 2009]

Function [Kottahachchi 2005] (Nombrada como Activity)

FunctionalPlace [Kottahachchi 2005]

Person [Kottahachchi 2005]


48

Resource [Kottahachchi 2005]

Path [Kottahachchi 2005], [Anagnostopoulos 2005]

Elevator [Dudas 2009]

Ramp [Dudas 2009]

Stairs [Dudas 2009]

Place [Chen 2003], [Kottahachchi 2005]

4.1.1.5 Conceptos añadidos.

Se añadieron conceptos que no se encontraron dentro de los modelos definidos en los trabajos

del estado del arte y que complementan la representación de espacios o que son necesarios

para los objetivos de esta tesis:

Access, AP (Access Point), BT (Bluetooth), RFIDTag, QRCode, RFIDReader, Space,

ElectricalStairs, FixedStairs

4.1.1.6 Glosario de términos.

Una vez definidos los conceptos se hace explícito a que nos referimos con cada uno de ellos

mediante el desarrollo de un glosario.

Nombre Descripción Tipo

Access Describe un punto límite que permite la entrada o salida a un

espacio

Concepto

Door Concepto raíz que agrupa atributos generales a los subconceptos de

tipo puerta

Concepto

AutomaticDoor Puerta en la que no es necesario tener una interacción física (tocar)

para su uso

Concepto

EmergencyDoor Tipo especial de puerta que se utiliza solamente en ocasiones de

emergencia

Concepto

ManualDoor Puerta de tipo general en la que es necesario tener una interacción

física (tocar)

Concepto

Function Una actividad que puede ser realizada en un lugar Concepto

FunctionalPlace Describe las acciones que pueden realizarse en un espacio dado Concepto


49

Person Entidad que representa a una persona de la vida real Concepto

Resource Un objeto dentro del control de una entidad en particular Concepto

AP Define un Access Point Wi-Fi Concepto

BT Define un Access Point Bluetooth Concepto

RFIDTag Define un tag RFID Concepto

QRCode Define un código de barras bidimensional Concepto

RFIDReader Define a un lector de tags RFID Concepto

Space Cualquier lugar en donde se puede ubicar a una persona u objeto Concepto

Path Describe un espacio que permite llegar de un lugar a otro Concepto

Elevator Dispositivo que permite trasladarse entre lugares de manera vertical Concepto

Ramp Tipo especial de camino utilizado generalmente por personas con

discapacidades

Concepto

Stairs Construcción diseñada para acceder a espacios en diferentes alturas Concepto

ElectricalStairs Escaleras que llevan de manera automática de un lugar a otro Concepto

FixedStairs Escaleras en las cuales es necesario subir sus escalones Concepto

Place Una entidad para representar un lugar del mundo real Concepto

containedIn Relación para denotar la contención entre espacios Relación

doesFunction Relación para definir el grupo de actividades que pueden realizarse

en un tipo de lugar

Relación

hasAccess Relación que asocia los accesos con los espacios para determinar

sus entradas o salidas

Relación

hasResource Relación para indicar que recursos están disponibles en un espacio

determinado

Relación

occupiedBy Relación que indica que persona se localiza de manera "estática" en

un lugar

Relación

worksAs Relación que asocia que funciones se realizan en un lugar Relación

identifiedBy Establece el tag rfid que con el que es identificada la persona Relación

name Define el nombre con el cual el elemento será identificado (legible

por humanos)

Atributo

maximumCapacity Define el número máximo de personas que pueden estar en el lugar Atributo

direction Define el sentido del acceso Atributo

MAC La dirección MAC de un dispositivo Atributo


50

value Establece el dato contenido dentro del recurso Atributo

amount Cantidad que indica el número de recursos del mismo tipo que se

encuentran en un lugar

Atributo

4.1.1.7 Taxonomía de conceptos.

Una vez identificados los conceptos a utilizar y teniendo claro que representa cada uno se

procede a categorizar y ordenarlos de forma jerárquica formando así la taxonomía de

conceptos.

Thing

o Access

Door

AutomaticDoor

EmergencyDoor

ManualDoor

o Function

o FunctionalPlace

o Person

o Resource

AP

BT

RFIDTag

QRCode

RFIDReader

o Space

Path

Elevator

Ramp

Stairs

o ElectricalStairs


51

o FixedStairs

Place

4.1.1.8 Diagrama de relaciones.

Teniendo las relaciones jerárquicas entre los distintos conceptos, se procede a establecer las

relaciones ontológicas que existen entre ellos.

Una vez definidos los conceptos y sus relaciones se crean los diccionarios que posteriormente

sirven de guía para la definición de la ontología dentro de algún software o su codificación en

OWL.

4.1.1.9 Diccionario de conceptos

Se define por cada concepto los atributos que puede tener así como sus relaciones con el resto

de los elementos.

Nombre Atributos Relaciones

Access direction, name --

Door direction, name --

AutomaticDoor direction, name --

EmergencyDoor direction, name --

ManualDoor direction, name --


52

Function name --

FunctionalPlace name doesFunction

Person name identifiedBy

Resource name --

AP name, MAC --

BT name, MAC --

RFIDTag name, value --

QRCode name, value --

RFIDReader name --

Space name,

maximumCapacity

containedIn, hasAccess, hasResource

Path name,

maximumCapacity


Elevator name,

maximumCapacity


Ramp name,

maximumCapacity


Stairs name,

maximumCapacity


ElectricalStairs name,

maximumCapacity


FixedStairs name,

maximumCapacity


Place name,

maximumCapacity

occupiedBy, worksAs, containedIn, hasAccess,

hasResource

4.1.1.10 Diccionario de relaciones

Se definen los dominios y rangos de las relaciones ontológicas encontradas.

Nombre Dominio Rango Tipo de relación

containedIn Space Space Transitiva

doesFunction FunctionalPlace Function --

hasAccess Space Access --


53

hasResource Space Resource --

identifiedBy Person RFIDTag Funcional

occupiedBy Place Person --

worksAs Place FunctionalPlace --

4.1.1.11 Diccionario de atributos

Se especifica por atributo los conceptos que los utilizan y el tipo de dato que van a almacenar.

Nombre Concepto Tipo

amount

direction Access Int {0,

1, 2}

MAC AP, BT String

maximumCapacity Space Int

name Access, Funtion,

Person,

FunctionalPlace,

Space, Resource

String

value QRCode,

RFIDTag

String

4.1.1.12 Definición formal de la ontología.

Para formalizar la ontología se utiliza la definición propuesta en [Ehrig 2006] que indica:

O:=(S, A, KB, Lex), donde O es una ontología, donde S es una ontología núcleo, A un

conjunto de axiomas, KB una base de conocimiento y Lex un léxico.

S:=(C, R, ≤C, ≤R, ), donde C es un conjunto de conceptos, R un conjunto de relaciones, ≤C

un orden parcial en C, ≤R un orden parcial en R y una función R CxC.


54

C = {Thing, Access, Door, AutomaticDoor, EmergencyDoor, ManualDoor, Function,

FunctionalPLace, PErson, REsource, AP, BT, QRCode, RFIDReader, RFIDTag, Space, Path,

Elevator, Ramp, Stairs, ElectricalStairs, FixedStairs, Place}

R = {containedIn, does function, hasAccess, hasResource, identifiedBy, occupiedBy,

worksAs}

*Por efectos prácticos y de espacio en ≤C se toma sólo como “<” y se anotan las relaciones

binarias que representan directamente la taxonomía.

≤C = {(Access, Thing), (Function, Thing), (FunctionalPlace, Thing), (Person, Thing),

(Resource, Thing), (Space, Thing), (Door, Access), (AutomaticDoor, Door), (EmergencyDoor,

Door), (ManualDoor, Door), (AP, Resource), (BT, Resource), (QRCode, Resource),

(RFIDReader, Resource), (RFIDTag, Resource), (Path, Space), (Place, Space), (Elevator,

Path), (Ramp, Path), (Stairs, Path), (ElectricalStairs, Stairs), (FixedStairs, Stairs)}

≤R = {(containedIn, doesFunction ), (containedIn, hasAccess), (containedIn, hasResource ),

(doesFunction, containedIn), (doesFunction, hasAccess), (doesFunction, hasResource),

(hasAccess, containedIn), (hasAccess, doesFunction), (hasAccess, hasResource),

(identifiedBy, containedIn), (identifiedBy, doesFunction), (identifiedBy, hasAccess),

(identifiedBy, hasResource), (occupiedBy, containedIn), (occupiedBy, doesFunction),

(occupiedBy, hasAccess), (occupiedBy, hasResource), (occupiedBy, worksAs), (worksAs,

containedIn), (worksAs, doesFunction), (worksAs, hasAccess), (worksAs, hasResource),

(worksAs, occupiedBy)}

= {containedIn (Space, Space), doesFunction (FunctionalPlace, Function), has Access

(Space, Access), hasResource (Space, Resource), identifiedBy (Person, RFIDTag),

occupiedBy (Place, Person), worksAs (Place, FunctionalPlace)}


55

A:=(AI, α), donde AI es un conjunto de identificadores de axiomas y α es un mapeo AI L

donde L es un lenguaje lógico.

No hay axiomas definidos.

*Se usan solo un pequeño conjunto de datos para demostrar la definición de base de

conocimiento y léxico.

KB:=(C, R, I, C, R), donde C y R están definidos igual que en S, I es el conjunto de

identificadores de instancias, C es una función de instanciación de conceptos y R una función

de instanciación de relaciones.

I = {PuertaPrincipalDCC, Practicas, Laboratorio, Ricardo, APAlumnos, RFIDTag_Ricardo,

EscalerasDCC, Cerritus, DCC, DCCPB, DCCPA, LSD}

C = {Access {PuertaPrincipalDCC}, Function {Practicas}, FunctionalPlace

{Laboratorio}, Person {Ricardo}, Resource {APAlumnos}, RFIDTAG

{RFIDTag_Ricardo}, FixedStairs{EscalerasDCC}, Place {Cerritus, DCC, DCCPB,

DCCPA, LSD}}

R = {containdedIn {(LSD, DCCPB), (DCCPB, DCC), (DCCPA, DCC), (EscalerasDCC,

DCC), (DCC, Cerritus)}, doesFunction {(Laboratorio, Practicas)}, hasAccess {(DCC,

PuertaPrincipalDCC), (DCCPB, EscalerasDCC), (DCCPA, EscalerasDCC)}, hasResource

{(DCCPB, APAlumnos)}, identifiedBy {(Ricardo, RFIDTag_Ricardo)}, occupiedBy

{(LSD, Ricardo)}, worksAS {(LSD,Laboratorio)}}

Lex := (GC, GR, GI, RefC, RefR, RefI), donde GC, GR, GI son conjuntos denominados signos

para conceptos, relaciones e instancias respectivamente y RefC, RefR, RefI son una relación de

referencias léxicas para conceptos, relaciones e instancias.


56

GC = {“Access”, “Door”, “AutomaticDoor”, “EmergencyDoor”, “ManualDoor”, “Function”,

“FunctionalPlace”, “Person”, “Resource”, “AP”, “BT”, “QRCode”, “RFIDReader”,

“RFIDTag”, “Space”, “Path”, “Elevator”, “Ramp”, “Stairs”, “ElectricalStairs”, “FixedStairs”,

“Place”}

GR = {“containedIn”, “does Function”, “has Access”, “hasResource”, “identifiedBy”,

“occupiedBy”, “worksAs”}

GI = {“PuertaPrincipalDCC”, “Practicas”, “Laboratorio”, “Ricardo”, “APAlumnos”,

“RFIDTag_Ricardo”, “EscalerasDCC”, “Cerritus”, “DCC”, “DCCPB”, “DCCPA”, “LSD”}

RefC = {(“Access”, Access), (“Door”, Door), (“AutomaticDoor” , AutomaticDoor),

(“EmergencyDoor” , EmergencyDoor), (“ManualDoor” , ManualDoor), (“Function” ,

Function), (“FunctionalPlace” , FunctionalPlace), (“Person” , Person), (“Resource” ,

Resource), (“AP” , AP), (“BT” , BT), (“QRCode” , QRCode), (“RFIDReader” , RFIDReader),

(“RFIDTag” , RFIDTag), (“Space” , Space), (“Path” , Path), (“Elevator” , Elevator), (“Ramp”

, Ramp), (“Stairs” , Stairs), (“ElectricalStairs” , ElectricalStairs), (“FixedStairs” , FixedStairs),

(“Place” , Place)}

RefR = {(“containedIn” , containedIn), (“doesFunction” , doesFunction), (“hasAccess” ,

hasAccess), (“hasResource” , hasResource), (“identifiedBy”, identifiedBy), (“occupiedBy” ,

occupiedBy), (“worksAs” , worksAs)}

RefI = {(“PuertaPrincipalDCC” , PuertaPrincipalDCC), (“Practicas” , Practicas),

(“Laboratorio” , Laboratorio), (“Ricardo” , Ricardo), (“APAlumnos”, APAlumnos),

(“RFIDTag_Ricardo”, RFIDTag_Ricardo), (“EscalerasDCC”, EscalerasDCC), (“Cerritus”,

Cerritus), (“DCC”, DCC), (“DCCPB”, DCCPB ), (“DCCPA”, DCCPA), (“LSD”, LSD)}

Aquí concluye la formalización de la ontología de infraestructura desarrollada en esta tesis. En

lo que resta del capítulo se define la parte correspondiente al análisis de los prototipos. En la


57

Figura 4-3 se muestra un diagrama de casos de uso que plantean de manera general los

prototipos software.

Figura 4-3 Casos de uso generales del conjunto de herramientas

A continuación se presentan a mayor profundidad los casos de uso.

4.1.2 Herramienta generadora de croquis.

En la Figura 4-4 se presenta el diagrama de caso de uso que corresponde a la herramienta que

nos permitirá manipular la información que estará contenida en los mapas SVG y obtener

como resultado un mapa con información contextual. Se puede observar los diferentes casos

de uso que nos permiten agregar mapas SVG al repositorio (CU 1.1), remover mapas

incorrectos del repositorio (CU 1.2), elegir sobre que mapa se desea trabajar y cuál es la

organización que representa (CU 1.3), manipular la información contenida en el mapa (CU

1.4) y por último, generar la salida del mapa SVG (CU 1.5).


58

Figura 4-4 Caso de uso 1. Generar croquis

De la Tabla 4-1 a la Tabla 4-10 se presentan las descripciones de los casos de uso mostrados

en la Figura 4-4, así como los diagramas de secuencia para cada uno de ellos de la Figura 4-5 a

la Figura 4-14.

Tabla 4-1 Descripción del caso de uso 1.1. Cargar croquis

Caso de uso CU1.1 Cargar croquis.

Descripción Permite al usuario ingresar un croquis a la aplicación.

Precondición El croquis debe de estar en formato SVG o SVG Tiny

Secuencia

normal

Acción

1. El usuario explora el sistema de archivos por el croquis que

desea cargar.

2. El usuario selecciona el croquis deseado.

3. El usuario da clic en el botón de carga.


59

Postcondición Un nuevo croquis en el repositorio y en la lista de croquis disponibles

Excepciones Acción

1. El croquis a cargar ya existe.

2. La aplicación sobrescribe el croquis antiguo con la versión

nueva.

Figura 4-5 Diagrama de actividad del caso de uso 1.1

Tabla 4-2 Descripción del caso de uso 1.2. Eliminar croquis

Caso de uso CU1.2 Eliminar croquis.

Descripción Le permite al usuario elegir un croquis incorrecto o innecesario y

eliminarlo del repositorio.

Precondición Debe existir al menos un croquis en el repositorio.

Secuencia Acción


60

normal 1. El usuario selecciona de la lista de croquis el que desea

eliminar.

2. El usuario da clic al botón eliminar.

3. La aplicación elimina del repositorio el croquis elegido.

Postcondición Una entrada menos en la lista de croquis disponibles.


Tabla 4-3 Descripción del caso de uso 1.3. Seleccionar croquis y organización

Caso de uso CU1.3 Seleccionar croquis y organización.

Descripción Permite al usuario definir el croquis sobre el cual va a trabajar y la

organización de la cual obtendrá información.

Precondición Debe existir al menos un croquis en el repositorio y una organización

definida en el almacén de tripletas.

Secuencia

normal

Acción

1. El usuario selecciona de la lista de croquis obtenida del CU1.7.

2. El usuario selecciona de una lista la organización a obtener

información proveniente del CU1.6.

3. El usuario da clic en el botón comenzar.

Postcondición Se muestra la pantalla principal de la aplicación.


61

Incluye CU1.6 Cargar organizaciones.

CU1.7 Cargar croquis existentes


Tabla 4-4 Descripción del caso de uso 1.4. Manipular información.

Caso de uso CU1.4 Manipular información.

Descripción Le permite al usuario asociar o desasociar la información contenida en

el croquis.

Precondición El usuario debe de encontrarse dentro de la pantalla principal de la

aplicación.

Secuencia

normal

Acción

1. El usuario ejecuta CU1.8 o el CU1.9

Postcondición La operación realizada debe verse reflejada en la interfaz gráfica.

Incluye CU1.8 Asociar información.

CU1.9 Desasociar información.


62


Tabla 4-5 Descripción del caso de uso 1.5. Generar croquis

Caso de uso CU1.5 Generar croquis.

Descripción Le permite al usuario guardar los cambios realizados a la información

asociada al croquis y recibir la última versión del croquis.

Precondición El usuario debe de estar en la pantalla principal de la aplicación.

Secuencia

normal

Acción

1. El usuario da clic en “generar”.

2. Abre el croquis del repositorio.

3. La aplicación guarda el croquis con los nuevos cambios.

4. La aplicación envía en una nueva ventana el croquis

recientemente creado.

Postcondición Un archivo SVG Tiny que contiene la información seleccionada en la

aplicación.


63


Tabla 4-6 Descripción del caso de uso 1.6. Cargar organizaciones

Caso de uso CU1.6 Cargar organizaciones.

Descripción Se encarga de realizar la consulta al almacén de tripletas y devolver la

lista de organizaciones existentes en él.

Precondición Debe estar disponible el almacén de tripletas.

Secuencia

normal

Acción

1. Se accede al almacén de tripletas.

2. Se buscan las instancias de tipo organización y sus subclases.

3. Por cada instancia obtenida se recuperan sus atributos de

nombre.

4. Se devuelven los nombres e identificadores de las

organizaciones.

Postcondición Una lista de las organizaciones disponibles.

Excepciones Acción

1. No se encuentra ninguna organización.

2. Se devuelve una lista vacía.


64


Tabla 4-7 Descripción del caso de uso 1.7. Cargar croquis existentes

Caso de uso CU1.7 Cargar croquis existentes.

Descripción Se encarga de realizar la consulta al repositorio de croquis y devolver

la lista de croquis existentes en él.

Precondición Debe estar disponible el repositorio de croquis.

Secuencia

normal

Acción

1. Se accede al repositorio de croquis.

2. Se leen los nombres de los archivos.

3. Se devuelven los nombres de los croquis.

Postcondición Una lista de croquis disponibles.

Excepciones Acción

1. No se encuentra ningún croquis.

2. Se devuelve una lista vacía.


65


Tabla 4-8 Descripción del caso de uso 1.8. Asociar información

Caso de uso CU1.8 Asociar información.

Descripción Permite relacionar la información contenida en el almacén de tripletas

a un elemento SVG del croquis.

Precondición El usuario debe encontrar en la pantalla principal de la aplicación.

Secuencia

normal

Acción

1. El usuario selecciona un elemento SVG al que desee asociarle

información.

2. El usuario selecciona la información que va a asociarle al

elemento, información proveniente de CU1.10.

3. El usuario da clic en el botón asociar.

4. La aplicación guarda en memoria la asociación y la

información.

Postcondición Una variable en memoria que registra el cambio de información.

Excepciones Acción

1. El elemento ya posee información asociada.

2. La información recién seleccionada reemplaza a la actual.


66


Tabla 4-9 Descripción del caso de uso 1.9. Desasociar información

Caso de uso CU1.9 Desasociar información.

Descripción Permite eliminar la relación de la información asociada a un elemento

SVG del croquis.

Precondición El usuario debe encontrar en la pantalla principal de la aplicación y el

elemento seleccionado debe tener información asociada previamente.

Secuencia

normal

Acción

1. El usuario selecciona un elemento SVG al que desee quitar

información.

2. El usuario da clic en el botón desasociar.

3. La aplicación elimina la información en memoria asociada.

Postcondición Eliminación de una variable en memoria


67


Tabla 4-10 Descripción del caso de uso 1.10. Cargar información de espacios

Caso de uso CU1.10 Cargar información de espacios.

Descripción Permite acceder a todos los datos encontrados en el almacén de

tripletas que correspondientes a un lugar específico.

Precondición El usuario debe haber seleccionado previamente un lugar.

Secuencia

normal

Acción

1. Se accede al almacén de tripletas.

2. Se localiza la instancia correspondiente al lugar seleccionado.

3. Se extraen las instancias de las personas asociadas a ese lugar.

4. Se extraen las instancias de las funciones asociadas a ese lugar.

5. Se extraen las instancias de las recursos asociadas a ese lugar

6. Se devuelven todos los valores recuperados de las consultas

Postcondición Una lista de valores correspondientes a un nombre de lugar, personas,

recursos y funciones.

Excepciones Acción

1. Si alguna categoría no tiene instancias, se devuelve esa

categoría vacía.


68


4.1.3 Módulo de edición automática.

La Figura 4-15 presenta el caso de uso 2. Editar mapa automáticamente que corresponde al

módulo que eliminará información del croquis en base a las recomendaciones recibidas en un

archivo XML proveniente de una solicitud de un dispositivo Android y posteriormente le

regresará la copia modificada del croquis al dispositivo. Para ello requerimos: recibir los datos

de la solicitud (CU2.1), enviar el croquis editado de vuelta al dispositivo móvil (CU1.2), por

lo que es necesario extraer los identificadores de los elementos recomendados (CU2.3) y

posteriormente se utilizar los identificadores obtenidos para modificar la información

contenida en el croquis (CU2.4).


69

Figura 4-15. Caso de uso 2. Editar croquis automáticamente.

De la Tabla 4-11 a la Tabla 4-14, se describen cada uno de los casos de uso involucrados en el

caso de uso 2. Las Figura 4-16 a la Figura 4-19 corresponden a los diagramas de actividad de

cada uno de los casos de usos contenidos en el caso de uso 2.

Tabla 4-11. Descripción del caso de uso 2.1. Recibir solicitud de datos.

Caso de uso CU2.1 Recibir solicitud de datos.

Descripción Se encarga de procesar el paquete que envía el dispositivo Android al

servidor para solicitar un croquis.

Precondición El módulo de edición automática de croquis debe de estar en ejecución.

Secuencia

normal

Acción

1. Se recibe la petición proveniente del dispositivo Android.

2. Se extrae el archivo XML de recomendaciones incluido con la

petición.

Postcondición Se obtiene un archivo XML que contiene los elementos que fueron

solicitados para resaltar en el croquis.


70

Figura 4-16. Diagrama de actividad del caso de uso 2.1

Tabla 4-12. Descripción del caso de uso 2.2. Enviar croquis editado.

Caso de uso CU2.2 Enviar croquis editado

Descripción Se encarga de mandar al dispositivo móvil que hizo la solicitud del

croquis la versión correspondiente a las recomendaciones de entrada.


Se debe tener el archivo XML de recomendaciones.

Secuencia

normal 1

Acción

1. Se ejecuta el CU2.3 y se almacenan los identificadores

recuperados del archivo XML.

2. Se ejecuta el CU2.4 y se envía al dispositivo móvil solicitante

la copia con modificaciones del croquis.

Postcondición El dispositivo móvil recibe un paquete con el croquis modificado.

Incluye CU2.3 Extraer ID de recomendaciones

CU2.4 Editar croquis en base a IDs


71


Tabla 4-13. Descripción del caso de uso 2.3. Extraer ID de recomendaciones.

Caso de uso CU2.3 Extraer ID de recomendaciones

Descripción Se encarga de analizar el archivo XML de recomendaciones y devolver

solamente los identificadores requeridos.


Se debe tener el archivo XML de recomendaciones.

Secuencia

normal

Acción

1. Se lee el archivo XML.

2. Por cada nodo se busca si corresponde a la acción para mostrar

en el croquis.

3. Cuando corresponda se busca el tipo de elemento recomendado

y se almacena en su propio arreglo.

Postcondición Se tiene un conjunto de arreglos que contienen los identificadores de

los elementos solicitados a mostrar en el croquis.


72


Tabla 4-14. Descripción del caso de uso 2.4. Editar croquis en base a IDs.

Caso de uso CU2.4 Editar croquis en base a IDs

Descripción Elimina la información innecesaria contenida en el croquis y denota los

elementos necesarios en base a las recomendaciones solicitadas.

Precondición Se debe haber ejecutado satisfactoriamente CU2.3.

Secuencia

normal

Acción

1. Por cada identificador en los arreglos se hace una búsqueda en

el croquis.

2. Si es encontrado, se almacena el identificador de la figura que

representa el lugar que le corresponde.

3. Se obtienen los identificadores de información asociada de cada

una de las figuras seleccionadas.

4. Se le agrega a cada figura seleccionada un efecto de animación

para resaltarla en el croquis.

5. Se recorre la sección de información adicional y si el

identificador de la información no se encuentra dentro de los


73

identificadores seleccionados, se elimina del croquis.

6. Se genera una copia del croquis con las modificaciones

realizadas.

Postcondición Se tiene un croquis con ubicaciones resaltadas y que contiene

solamente información de dichas ubicaciones.



74

4.1.4 Visualizador SVG.

La Figura 4-20 presenta el caso de uso 3. Visualizar croquis, que corresponde al visualizador

en el dispositivo Android que permite interactuar con la versión modificada del croquis. El

visualizador se encarga de recibir el croquis y mostrarlo en pantalla (CU3.1), una vez cargado

el croquis es posible hacer operaciones de acercamiento (zoom in) y alejamiento (zoom out),

así como desplazarlo por la pantalla y restablecerlo a su vista original. (CU3.3 a CU3.6

respectivamente), otras posibilidades son moverse a través de las capas incluidas en el croquis

(CU3.7) y examinar la información adicional que tienen asociadas las figuras (CU3.8).

Figura 4-20. Caso de uso 3. Visualizar croquis.


75

De la Tabla 4-15 a la Tabla 4-22, se describen cada uno de los casos de uso involucrados en el

caso de uso 3. Las Figura 4-21 a la Figura 4-27 corresponden a los diagramas de actividad de

cada uno de los casos de usos de que conforman el caso de uso 3.

Tabla 4-15. Descripción del caso de uso 3.1. Cargar croquis.

Caso de uso CU3.1 Cargar croquis

Descripción Recibe el croquis y lo despliega en la pantalla del visualizador.

Precondición Se debe de haber recibido el croquis modificado del CU2.2

Secuencia

normal 1

Acción

1. Se recibe el paquete que contiene el croquis SVG.

2. Se extrae el archivo SVG.

3. Se parsea el archivo SVG.

4. Se generan la imagen.

5. Se rasteriza el croquis en pantalla.

Postcondición Se tiene un croquis con ubicaciones resaltadas que contienen solamente

información de dichas ubicaciones.

Excepciones Acción

1. El archivo recibido no es SVG versión Tiny.

2. No se despliega en pantalla ningún croquis


76


Tabla 4-16 Descripción del caso de uso 3.2. Interactuar con croquis

Caso de uso CU3.2 Interactuar con croquis.

Descripción Le permite al usuario realizar diversas acciones que afectan la

información visual.

Precondición El usuario debe encontrarse dentro de la pantalla principal de la

aplicación y tener cargado un mapa

Secuencia

normal

Acción

1. El usuario puede realizar del CU3.3 al CU3.8

Postcondición La operación realizada debe verse reflejada en la interfaz gráfica.

Incluye CU3.3 Zoom in

CU3.4 Zoom out


77

CU3.5 Panning

CU3.6 Reset

CU3.7 Cambiar capa

CU3.8 Examinar información del croquis

Tabla 4-17. Descripción del caso de uso 3.3. Zoom in.

Caso de uso CU3.3 Zoom in

Descripción Permite aumentar el tamaño de la imagen actual en pantalla.

Precondición Debe existir un croquis cargado.

Secuencia

normal

Acción

1. El usuario da clic en el botón de zoom in.

2. Se agranda la imagen al doble.

3. Se muestra la nueva imagen en pantalla.

Postcondición Una imagen más grande del croquis previo.


Tabla 4-18. Descripción del caso de uso 3.4. Zoom out.

Caso de uso CU3.4 Zoom out


78

Descripción Permite disminuir el tamaño de la imagen actual en pantalla.


Secuencia

normal 1

Acción

1. El usuario da clic en el botón de zoom in.

2. Se encoge la imagen a la mitad.

3. Se muestra la nueva imagen en pantalla.

Postcondición Una imagen más pequeña del croquis previo.


Tabla 4-19. Descripción del caso de uso 3.5. Panning.

Caso de uso CU3.5 Panning

Descripción Permite hacer un desplazamiento del croquis en cualquier dirección.


El visualizador debe estar en modo de desplazamiento.

Secuencia

normal 1

Acción

1. El usuario coloca su dedo sobre la pantalla como punto de

referencia para el desplazamiento.

2. El usuario desplaza su dedo en cualquier dirección.


79

3. Se desplaza el mapa en la dirección y magnitud que el usuario

desplazó su dedo.

Postcondición Se tiene un croquis con ubicaciones resaltadas y que contiene

solamente información de dichas ubicaciones.


Tabla 4-20. Descripción del caso de uso 3.6. Reset

Caso de uso CU3.6 Reset

Descripción Restablece el croquis a la posición y tamaño inicial de carga.


Secuencia

normal 1

Acción

1. El usuario da clic al botón de reset.

2. El croquis es cargado con sus valores de posición y tamaño por

default nuevamente.

3. Se despliega en pantalla el croquis

Postcondición El croquis en pantalla en su tamaño y posición inicial.


80


Tabla 4-21. Descripción del caso de uso 3.7. Cambiar capa

Caso de uso CU3.7 Cambiar capa

Descripción Permite al usuario cambiar la capa activa del croquis y así el contenido

desplegado en pantalla


Secuencia

normal

Acción

1. El usuario selecciona la opción de cambiar capa.

2. Se despliega en pantalla una lista de las capas disponibles.

3. El usuario selecciona la capa que desea mirar.

4. Se inhabilita la capa actual y se habilita la capa seleccionada del

croquis.

5. Se refresca la imagen en pantalla para reflejar los cambios.

Postcondición Se despliega una nueva vista del croquis correspondiente a la capa

seleccionada.

Excepciones Acción


81

1. La capa seleccionada por el usuario es la misma que la capa

actual.

2. No se hace modificación alguna y se devuelve a la pantalla del

croquis.

Incluye


Tabla 4-22. Descripción del caso de uso 3.8. Examinar información del croquis

Caso de uso CU3.8 Examinar información del croquis

Descripción Permite desplegar la información asociada a una figura del croquis.


El visualizador debe estar en modo fijo.


82

Debe de existir información asociada a la figura.

Secuencia

normal 1

Acción

1. El usuario da clic a una figura.

2. Se extraen los datos del croquis.

3. Se despliegan los datos en una ventana emergente.

Postcondición Desplegar ventana emergente con los datos asociados a la figura que se

seleccionó.


4.2 Diseño.

El proyecto de tesis consiste de tres herramientas: la aplicación para generar croquis, el

módulo para editarlos automáticamente en base a un conjunto de recomendaciones y el

visualizador de mapas; donde este último desde una perspectiva cliente-servidor, trabaja en el

lado cliente en el dispositivo Android mientras que los dos previos trabajan en el lado

servidor.

4.2.1 Herramienta generadora de croquis

La herramienta para la generación de croquis con información semántica se encuentra en el

paquete mx.edu.cenidet.Ont2SVG, la cual consta de 3 clases:


83

Configuration. Esta clase se encarga de mantener las constantes de las URIs de los

elementos de la ontología a consultar por la aplicación y también de constantes de la

ubicación del almacén de tripletas y el repositorio de croquis.

Inicio. Es la clase que trabaja la página inicial de la aplicación, se encarga de la carga y

eliminación de croquis en el repositorio, así como de la búsqueda de las organizaciones

en el almacén de tripletas.

SessionHandler. Trabaja todos los aspectos de asociación y desasociación de

información en los elementos SVG en memoria.

Figura 4-28 Diagrama de clases de la Herramienta generadora de croquis

Existe un segundo paquete, mx.edu.cenidet.Ont2SVG.Objetos, que contiene las clases que

funcionan como estructuras de datos básicas del sistema, consta de 5 clases:

Organization. Es la plantilla para contener los datos necesarios de las organizaciones

extraídas del almacén de tripletas.


84

Place. Es la plantilla para contener los datos necesarios de los lugares extraídos del

almacén de tripletas.

Person. Es la plantilla para contener los datos utilizados de las personas extraídas del


Resource. Es la plantilla para contener los datos utilizados de los recursos extraídos del


ExtraInformation. Es la estructura que permite agrupar toda la información (lugar,

personas, recursos, funciones) acerca de un espacio determinado en un solo objeto.

A continuación, se presentan los diagramas de secuencia que involucran la funcionalidad de la

herramienta.

La Figura 4-29 representa la carga de un nuevo croquis a la aplicación, para ello:

1. La aplicación verifica el objeto de configuración para obtener la ruta del repositorio.

2. La aplicación valida que la entrada de datos (el archivo SVG) sea válido.

Figura 4-29 Diagrama de secuencia para la carga de croquis

La Figura 4-30 representa la eliminación de un croquis que se encuentra en el repositorio,

realizando lo siguiente:

1. La aplicación verifica el objeto de configuración para obtener la ruta del repositorio.

2. La aplicación obtiene la lista de croquis que se encuentran en el repositorio.


85

3. Después de que el usuario elija el croquis, se elimina del repositorio.

Figura 4-30 Diagrama de secuencia para la eliminación de croquis

La Figura 4-31 representa la selección de croquis y organización sobre la que se trabajará,

realizando lo siguiente:

1. La aplicación verifica el objeto de configuración para obtener la ruta del repositorio y


2. La aplicación obtiene la lista de croquis que se encuentran en el repositorio.

3. La aplicación obtiene la lista de organizaciones que se encuentran en el almacén de

tripletas.

4. Después de que el usuario elija el croquis y la organización, la ejecución se traslada a

otro objeto el cual:

a. Obtiene todos los identificadores de los elementos SVG contenidos en el

archivo.

b. Carga del repositorio de tripletas los lugares registrados para la organización

seleccionada.


86

Figura 4-31 Diagrama de secuencia para la selección de croquis y organización

La Figura 4-32 representa la asociación de información en memoria a un elemento SVG del

croquis, realizando lo siguiente:

1. Se despliega la información actual del elemento seleccionado.

2. Se carga del almacén de tripletas la información referente al lugar seleccionado.

3. Se agrega o reemplaza la información de memoria con la proveniente del almacén de

tripletas.

4. Se recarga la información actual del elemento seleccionada, que ya corresponde a la

que se encuentra en el almacén de tripletas.


87

Figura 4-32 Diagrama de secuencia para la asociación de información

La Figura 4-33 representa la desasociación de información en memoria a un elemento SVG

del croquis, realizando lo siguiente:

1. Se despliega la información actual del elemento seleccionado.

2. Se elimina la información de memoria para el elemento en cuestión.

3. Se recarga la información actual del elemento seleccionada, que debe estar vacía.


88

Figura 4-33 Diagrama de secuencia para la desasociación de información

La Figura 4-34 representa el salvado de los cambios realizados a la información asociada al

croquis, realizando lo siguiente:

1. Se invoca el método de guardado.

2. Por cada elemento en memoria que corresponde a información asociada, se obtiene los

datos necesarios para poblar el croquis.

Figura 4-34 Diagrama de secuencia para generar croquis


89

4.2.2 Módulo de edición automática.

Este módulo se encuentra dentro del paquete mx.edu.cenidet.SVGAutoEdit y consta de tres

clases:

SVGAutomaticEditor. Es la parte central del módulo donde se procesa el paquete que

trae las recomendaciones y se devuelve el croquis modificado.

RecommendationParser. Se encarga de recibir el archivo XML de recomendaciones y

extraer de él los identificadores de los objetos a resaltar.

SVGModifier. Se encarga de utilizar los identificadores extraídos de las

recomendaciones para buscar en el mapa los lugares a marcar y eliminar la

información asociada que no sea necesaria.

La Figura 4-35 muestra el diagrama de clases correspondiente al paquete

mx.edu.cenidet.SVGAutoEdit.

Figura 4-35. Diagrama de clases de el módulo de edición automática.

A continuación se presenta en la Figura 4-36 el diagrama de secuencia del módulo de edición

automática de croquis con los métodos principales utilizados. El proceso se lleva a cabo de la

siguiente manera:


90

1. El objeto SVGAutomaticEditorExample hace uso del método

RecommendationParser() con el cual se le envía al objeto RecommendationPaser el

archivo XML que contiene las recomendaciones.

2. Se ejecuta el método searchIds() que buscará dentro del XML los identificadores que

están marcados para ser mostrados en el croquis.

3. Se ejecuta searchPlacesByPersons() con el cual se obtienen los lugares en los cuales

normalmente se puede localizar a las personas cuyo identificador se encuentra en la

lista de identificadores obtenida.

4. Se ejecuta searchPlacesByResource() con el cual se obtienen los lugares en los cuales

se pueden localizar los recursos cuyo identificador se encuentra en la lista de

identificadores obtenida.

5. Se elimina la información innecesaria del croquis con deleteUnnecesaryInformation().

6. Se agregan los efectos de animación a las figuras necesarias con

setRecommendationAnimation().

7. Por último se solicita crear la copia con las modificaciones realizadas en el croquis.


91

Figura 4-36. Diagrama de secuencia del módulo de edición automática.

4.2.3 Visualizador SVG.

Este módulo se encuentra dentro del paquete mx.edu.cenidet.SVGViewer y consta de las

siguientes clases principales:

SVGDisplay. Es la actividad principal del sistema y por tanto el punto de entrada del

mismo, contiene a los demás objetos que conforman el sistema como la clase del

visualizador y los controles de interacción principales.

FileOpenActivity. Es la actividad que permite recorrer el sistema de archivos del

dispositivo en busca de un croquis y seleccionarlo para su despliegue en pantalla.

LayerListActivity. Es la actividad que permite al usuario seleccionar la capa del

croquis que desea visualizar en un momento dado.


92

LocationActivity. Es la actividad que permite emular el comportamiento en el cual

llegan una actualización de posición al dispositivo.

PlayerControls. Es la definición de los controles primarios de interacción.

PlayerListener. Contiene la implementación del comportamiento de cada elemento de

la interfaz.

SVGSurfaceView. Es el control que permite mostrar en pantalla el contenido del SVG.

La Figura 4-37 muestra el diagrama de clases del paquete mx.edu.cenidet.SVGViewer con las

clases más relevantes.


93

Figura 4-37. Diagrama de clases del visualizador de SVG.

A continuación se presenta los diagramas de secuencia que involucran la funcionalidad del

visualizador con los métodos principalmente utilizados. La Figura 4-38 representa la carga del

archivo SVG en el visualizador, en donde sucede lo siguiente:

1. La clase principal manda a crear a FileOpenActivity.

2. Se selecciona el archivo que se desea y se regresa a la clase principal.

3. Se solicita al control de visualización que cargue el archivo seleccionado.


94

Figura 4-38. Diagrama de secuencia para la carga del archivo SVG.

La Figura 4-39 muestra el diagrama de secuencia para el evento de zoom in y zoom out, la

diferencia se encuentra en la función zoom() de donde su parámetro indica si el zoom es

positivo o negativo. La secuencia es como se describe a continuación:

1. Al hacer clic en el botón de zoom, PlayerListener actúa a través de handleEvent() y

resuelve que se trata de un zoom.

2. Dependiendo del botón el parámetro de entrada a la función zoom() indicará si se trata

de un zoom in o out.

3. Se solicita al control de visualización que aplique el cambio realizado al croquis.


95

Figura 4-39. Diagrama de secuencia para el zoom in y zoom out.

La Figura 4-40 muestra el diagrama de secuencia para el evento de panning, funciona de la

siguiente manera:

1. El control de visualización detecta y registra el movimiento del dedo sobre la pantalla.

2. Se le envía la señal de movimiento al PlayerListener para ejecute el código pertinente.

3. PlayerListener ejecuta la función pan() con las nuevas coordenadas.

4. El control de visualización se actualiza.


96

Figura 4-40. Diagrama de secuencia para el panning.

La Figura 4-41 muestra el diagrama de secuencia para el evento de reset. La secuencia es

como se describe a continuación:

1. Al hacer clic en el botón de reset, PlayerListener actúa a través de handleEvent() y

resuelve que se trata de un reset.

2. Se ejecuta el método origView() que devuelve el croquis a su estado original.

3. Se solicita al control de visualización que aplique el cambio realizado al croquis.


97

Figura 4-41. Diagrama de secuencia para el reset.

La Figura 4-42 muestra el diagrama de secuencia para cuando se desea cambiar la capa visible

del croquis. La secuencia es como se describe a continuación:

1. La actividad principal lanza la actividad en donde se escriben las coordenas que se

desean marcar.

2. Se ejecuta la función setLocation() teniendo como parámetros las coordenas X y Y

obtenidas en la actividad secundaria.

3. Se solicita al control de visualización que aplique la actualización realizada al croquis.


98

Figura 4-42. Diagrama de secuencia para el cambio de capa del croquis.

Capítulo 5 Implementación.

Capítulo 5 Implementación

100

El trabajo cuenta de tres herramientas: el visualizador SVG para dispositivos móviles basados

en Android, el módulo de edición automática de croquis y la herramienta para la creación y

edición de croquis como se muestra en la Figura 5-1.

Figura 5-1 Interacción entre las herramientas desarrolladas

5.1 Herramienta para la generación de croquis.

La herramienta para la generación de croquis con información semántica se implementó como

una aplicación web utilizando el framework Struts 2 y la API de Jena y TDB para el acceso al


La aplicación web consta de dos páginas, en las cuales se realizan todas las operaciones

definidas en el análisis y diseño.


101

Figura 5-2 Pantalla inicial de la aplicación

La Figura 5-2 muestra la pantalla inicial de la aplicación, en ella se encuentran los siguientes

elementos y acciones disponibles:

1. Permite seleccionar el croquis con el que se va a trabajar.

2. Permite seleccionar la organización de la que se extraerán datos.

3. Una vez seleccionados los elementos 1 y 2, permite pasar a la página principal de la

aplicación

4. Permite seleccionar un croquis que se desea eliminar.

5. Una vez seleccionado el elemento 4, envía la orden de eliminar el croquis y recargar la

página.

6. Permite acceder al sistema de archivos y seleccionar un croquis que se desee cargar

para usar en la aplicación.

7. Ejecuta la opción de carga del croquis y recarga la página.


102

Figura 5-3 Pantalla principal de la aplicación web (Parte 1)

La Figura 5-3 muestra la pantalla principal de la aplicación, en ella se encuentran los

siguientes elementos y acciones disponibles:

1. Despliega el nombre de la organización de la cual se están extrayendo datos.

2. Es la ayuda visual que permite determinar con que elemento del croquis se está

trabajando.

3. Permite seleccionar la capa del croquis que se desea observar.

4. Permite seleccionar el elemento SVG con el que se va a trabajar.

5. Permite seleccionar un espacio de la organización para extraer sus datos.

6. Una vez seleccionados los elementos 4 y 5, permite asocial al elemento 1 de la Figura

5-4 la información contendida en 2 de la Figura 5-4, haciéndose notar la asociación

mediante la recarga del elemento 1 de la Figura 5-4.


103

Figura 5-4 Pantalla principal de la aplicación web (Parte 2)

En la Figura 5-4 continúa la descripción de la pantalla principal, en ella se tienen:

1. Esta tabla muestra los datos asociados a un elemento y se actualiza en base a lo

seleccionado en 1.

2. Despliega la información proveniente del almacén de tripletas que corresponde al

espacio seleccionado en el elemento 5 de la Figura 5-3.

3. Permite deshacer la asociación de la información desplegada en 1 al elemento 4 de la

Figura 5-3.


104

4. Realiza la acción de guardar los cambios realizados a la información asociada al

croquis y posteriormente envía al usuario el croquis con los cambios realizados.

5.2 Módulo de edición automática de croquis.

A continuación se describe la implementación de este módulo el cual utiliza dos archivos de

entrada; el croquis SVG que se quiere modificar y el archivo XML que contiene las

recomendaciones que son el criterio para aplicar los cambios. La estructura de los archivos

está en descrita en el Anexo A2. Formato del archivo de recomendaciones XML y más

adelante el Anexo A3. Formato del archivo SVG.

Figura 5-5 Interfaz gráfica del editor automático de croquis

La ejecución del módulo es a través de un archivo JAR autoejecutable. A continuación se

describe su interfaz gráfica, mostrada en la Figura 5-5:

1. Permite buscar en el sistema de archivos el archivo SVG que se desea modificar.

2. Permite buscar en el sistema de archivos el archivo XML de recomendaciones que se

va a utilizar.


105

3. Permite definir la ruta en donde se creará el nuevo archivo SVG que contendrá

solamente la información solicitada en las recomendaciones.

4. Habiendo llenado los puntos 1 a 3, permite realizar el proceso de filtrado al mapa

SVG.

5. Describe el estado del proceso de filtrado.

5.3 Visualizador SVG.

El visualizador SVG está diseñado para trabajar con el archivo SVG del croquis modificado,

aunque trabajar con una versión completa no presenta problema alguno. El archivo debe tener

la estructura que se presenta en el Anexo A3. Formato del archivo SVG.

La Figura 5-6 muestra la pantalla principal del visualizador, consta de un menú inferior para

manipular la visualización de la imagen.

Figura 5-6. Pantalla inicial del visualizador.

La Figura 5-7 muestra el menú inferior con mayor detalle. De izquierda a derecha se

encuentran el botón para hacer zoom in, zoom out, activar el modo de panning o el modo fijo

y restablecer el croquis a su vista original.


106

Figura 5-7. Menú inferior del visualizador.

La Figura 5-8 muestra un menú oculto de la aplicación que permite acceder a tres actividades,

que son: abrir un croquis, establecer una nueva localización y cambiar el plano del croquis.

Figura 5-8. Menú oculto del visualizador.

La Figura 5-9 muestra el cuadro de texto donde se escribe la URI del croquis que se desea

cargar.

Figura 5-9. Carga del croquis en el visualizador.

La Figura 5-10 muestra la transición de la imagen de su estado original a una imagen con

acercamiento y luego con un alejamiento.


107

Figura 5-10. Zoom in y zoom out.

La Figura 5-11 exhibe el comportamiento de desplazamiento o panning.

Figura 5-11. Panning.

La Figura 5-12 refleja la acción de restaurar una imagen a su vista original.


108

Figura 5-12. Reset.

La Figura 5-13 muestra del lado izquierdo la pantalla sobre la cual se introducen las

coordenadas del punto que representa la ubicación del dispositivo y como es mostrado en el

croquis en el lado derecho.

Figura 5-13. Localización

La Figura 5-14 muestra del lazo izquierdo la interfaz para seleccionar la capa que se desea

mostrar y del lado derecho el cambio que se realizó al seleccionar una capa diferente.


109

Figura 5-14. Cambio de capas

Capítulo 6 Pruebas

Capítulo 6 Pruebas

111

Bitácora de prueba HGC-04-01.

Descripción: Ésta bitácora corresponde al procedimiento de prueba HGC-03-01 definido

en el plan de pruebas PP-01.

Hace uso de un croquis (cerritus.svg) creado en el editor svg-edit y se encarga de verificar

que el croquis a utilizar en las subsecuentes pruebas cumpla con las condiciones

especificadas, proporcionando como salida la lista de identificadores de los elementos SVG

contenidos en el croquis.

Las imágenes de pruebas definidas en el archivo con sus identificadores de capas

respectivos son los siguientes:

Figura 6-1 Imágenes del archivo de pruebas por capas

Se verifica que el código fuente cumpla las condiciones establecidas en la definición de la

prueba:

Figura 6-2 Croquis de prueba que cumple con los requisitos del caso de prueba HGC-03-01

Se devuelve una lista de identificadores generada por orden de aparición como se muestra a

continuación:

Capítulo 6 Pruebas

112

cerritus

pasillos

cerritus_estacionamiento

cerritus_estacionamiento1

cerritus_dcc

cerritus_del

cerritus_dad

cerritus_Vigilancia

lineas

dad_pb

planta

dad_pb_cafeteria

dad_pb_WCdamas

dad_pb_Depto_MatyServ

dad_pb_Jefe_DeptoMatySe

rv

dad_pb_Jefe_DeptoRecFin

an

dad_pb_Almacen

dad_pb_jefe_DeptoPlan

dad_pb_Sub_Acad

dad_pb_Sub_PlanyVinc

dad_pb_Direccion

dad_pb_WCcaballeros

dad_pb_Depto_RecFinan

dad_pb_Depto_Plan

dad_pb_Sub_Adm

dad_pb_WCcafeteriaf

dad_pb_WCdirector

dad_pb_escaleras

dad_pb_lineas_divisoras

dad_pa

planta

dad_pa_WCcaballeros

dad_pa_Dpto_GestionTecy

Vinc

dad_pa_Jefe_ComyEven

dad_pa_Dpto_ComyEven

dad_pa_SalaJuntas

dad_pa_Vitrina

dad_pa_Jefe_DptoGestionT

ecyVinc

dad_pa_desconocido

dad_pa_Jefe_DeptoOrgySe

gEst

dad_pa_WCDamas

dad_pa_Ofi_ServEst

dad_pa_Oficina_RegyCtrl

dad_pa_Jefe_DptoServEsc

dad_pa_Archivos_Personal

dad_pa_Ofi_CtrlEsc

dad_pa_Jefe_ServPer

dad_pa_Jefe_RH

dad_pa_Sub_Acad

dad_pa_desconocido2

dad_pa_escaleras

lineas

dcc_pb

planta

dcc_pb_WCHombres

dcc_pb_WCDamas

dcc_pb_bodega

dcc_pb_Aula_1

dcc_pb_Aula_2

dcc_pb_Aula_3

dcc_pb_Mantenimiento

dcc_pb_lab_IA

dcc_pb_lab_IS

dcc_pb_lab_SD

dcc_pb_escaleras

dcc_pb_lineas_divisoras

dcc_pa

planta

dcc_pb_WCHombres

dcc_pb_WCDamas

dcc_pa_bodega

dcc_pa_Jefatura

dcc_pa_SalaJuntas

dcc_pa_cubo_01

dcc_pa_cubo_02

dcc_pa_cubo_03

dcc_pa_cubo_04

dcc_pa_cubo_05

dcc_pa_cubo_06

dcc_pa_cubo_07

dcc_pa_cubo_08

dcc_pa_cubo_09

dcc_pa_cubo_10

dcc_pa_cubo_11

dcc_pa_cubo_12

dcc_pa_cubo_13

dcc_pa_cubo_14

dcc_pa_cubo_15

dcc_pa_cubo_16

dcc_pa_cubo_17

dcc_pa_cubo_18

dcc_pa_cubo_19

dcc_pa_cubo_20

dcc_pa_cubo_21

dcc_pa_cubo_22

dcc_pa_escaleras

dcc_pa_lineas_divisoras

del_pb

planta

del_pb_Almacen

del_pb_lab_Iluminacion

del_pb_lab_control

del_pb_Bodega

del_pb_lab_circuitosImp

del_pb_lab_maquinasElec

del_pb_WCcaballeros

del_pb_intendencia

del_pb_lab_potencia

del_pb_aula_3

del_pb_centro_computo

del_pb_aula_5

del_pb_aula_4

del_pb_aula_2

del_pb_sala_audiovisual

del_pb_acceso_Site

del_pb_site

del_pb_aula_1

del_pb_Jefatura_labs

del_pb_escaleras

del_pb_linea_divisora

del_pa

planta

del_pa_alum_mecatronica

del_pa_biblioteca

del_pa_WCcaballeros

del_pa_Jefatura_CentroInfo

del_pa_cubo2201

del_pa_cubo2202

del_pa_cubo2203

del_pa_cubo2204

del_pa_cubo2205

del_pa_cubo2206

del_pa_cubo2207

del_pa_cubo2208

del_pa_cubo2209

del_pa_cubo2210

del_pa_cubo2211

del_pa_cubo2212

del_pa_cubo2213

del_pa_cubo2214

del_pa_cubo2215

del_pa_cubo2216

del_pa_cubo2217

del_pa_cubo2218

del_pa_cubo2219

del_pa_cubo2220

del_pa_cubo2221

del_pa_alumnos_maestria

Capítulo 6 Pruebas

113

del_pa_SalaJuntas

del_pa_alumnos_doctorado

lineas Divisoras

del_pa_escaleras


Descripción: Ésta bitácora corresponde al procedimiento de prueba HGC-03-02 definido en el

plan de pruebas PP-01.

Hace uso de un croquis (cerritus.svg) verificado previamente con HGC-04-01 y se encarga de

realizar la asociación de información proveniente de la ontología a los elementos SVG del

croquis.

Figura 6-3 Carga de croquis en la aplicación

Se elige el archivo recién agregado y la organización de la cual se extraerá información:

Figura 6-4 Selección de croquis y organización para trabajo

Se comienza asociar información a los elementos SVG y registrar a qué elemento se le asoció

información (para efectos de prueba y espacio se le aplica solo a 3 elementos en diferentes

capas):

Capítulo 6 Pruebas

114

Figura 6-5 Asociación de información al primer elemento

Capítulo 6 Pruebas

115

Figura 6-6 Asociación de información al segundo elemento

Capítulo 6 Pruebas

116

Figura 6-7 Asociación de información al tercer elemento

Capítulo 6 Pruebas

117

Después del proceso de asociación la lista (identificador, información) queda como en la

siguiente tabla:

Tabla 6-1 Identificadores seleccionados con su información asociada

Identificador Información

dcc_pb_Aula_2 Aula 2 DCC, Cañón Proyector, Pantalla de proyección, Pintarrón,

Smartboard, Proyector de acetatos, Impartir Clases, Asesorías

educacionales, Área de estudio, Impartir conferencias.

Dcc_pa_cubo_10 Cubículo 10, Juan Gabriel González, Impresora, Multifuncional,

Investigación Tecnológica, Asesorías Educacionales, Asesorías.

dad_pb_cafeteria Bodega, Administración de información, Recepción de documentos,

Control Académico, Juntas académicas, Juntas Informativas, Exposición

de temas relevantes, Toma de decisiones.




Continúa con la ejecución realizada de HGC-04-02 y se encarga de verificar que la

información asociada en la prueba HGC-04-02 esté realmente en el croquis.

Se verifica que los elementos seleccionados tengan el atributo xlink:href correspondiente:

Figura 6-8 Verificación de atributo xlink:href en el primer elemento

Figura 6-9 Verificación de atributo xlink:href en el segundo elemento

Capítulo 6 Pruebas

118

Figura 6-10 Verificación de atributo xlink:href en el tercer elemento

Se verifica que exista la información asociada dentro de la etiqueta <defs>

Se cumplen las condiciones de la prueba.




Se utiliza el archivo generado en HGC-04-03 y se anota la información asociada que contiene.

Se obtiene una lista mostrada en la Tabla 6-2.

Tabla 6-2 Información asociada dentro del croquis





Dcc_pa_cubo_10 Cubículo 10, Juan Gabriel González, Impresora, Multifuncional,


dad_pb_cafeteria Bodega, Administración de información, Recepción de documentos,

Control Académico, Juntas académicas, Juntas Informativas, Exposición

Capítulo 6 Pruebas

119

de temas relevantes, Toma de decisiones.

Se procede a verificar que la información asociada en el croquis corresponde a la información

que se encuentra dentro de la aplicación.

Figura 6-11 Verificando correspondencia de información para el primer elemento

Figura 6-12 Verificando correspondencia de información para el segundo elemento

Capítulo 6 Pruebas

120

Figura 6-13 Verificando correspondencia de información para el tercer elemento

Capítulo 6 Pruebas

121




Se registran los cambios realizados a través de la aplicación a un croquis existente que posea

información asociada generando una lista de salida de los identificadores de los elementos y su

información asociada correspondiente.

Se elige un elemento, en este caso dad_pb_cafeteria y se le desasocia la información adicional

que contiene.

Figura 6-14 Desasociación de información a un elemento

Capítulo 6 Pruebas

122

Se agrega información a un nuevo elemento y se verifica que el elemento esté vinculado a la

información.

Figura 6-15 Asociación de información a un nuevo elemento

Capítulo 6 Pruebas

123

Al terminar la prueba el registro de cambios queda de la siguiente manera:





dcc_pa_cubo_10 Cubículo 10, Juan Gabriel González, Impresora, Multifuncional,


dad_pb_cafeteria Sin información

dad_pb_Depto_RecFinan Departamento de recursos financieros, María del Rocío Brito, Irma

Bustamante, Silvia Muñoz, Administración de Información,

Recepción de documentos, Control académico, Juntas

Académicas, Juntas Informativas, Exposición de temas relevantes,

Toma de decisiones.




Se verifica que los cambios realizados a través de la aplicación a un croquis existente se vean

reflejados en el archivo de salida de que genera la aplicación.

Se verifica que todos los elementos con información tengan su atributo xlink:href:

Figura 6-16 Verificación del atributo xlink:href para el primer elemento después de la reasociación

Figura 6-17 Verificación del atributo xlink:href para el segundo elemento después de la reasociación

Capítulo 6 Pruebas

124

Figura 6-18 Verificación del atributo xlink:href para el tercer y cuarto elemento después de la reasociación

Se observa que el elemento dad_pb_cafeteria conserva su atributo de enlace, pero ya no existe

información definida para él.

Figura 6-19. Información existente depués de desasociar información.

En la Figura 6-19 observa que se encuentra toda la información adicional en los elementos que

corresponden y que dad_pb_cafeteria no tiene información asociada.

Capítulo 6 Pruebas

125

Bitácora de prueba MEA-04-01.

Descripción: Ésta bitácora corresponde al procedimiento de prueba MEA-03-01 definido en el


Se verifica que se conserve únicamente la información indicada en el archivo de

recomendaciones.

Para esto se genera el siguiente archivo XML que contiene un conjunto de recomendaciones

de prueba.

Figura 6-20 Archivo de recomendaciones a utilizar

Del anterior archivo se obtiene que se requiere conservar únicamente los lugares donde se

encuentre la persona con identificador 000000103 y el recurso con identificador 20000009.

Capítulo 6 Pruebas

126

Se obtiene la siguiente información del croquis modificado:

Figura 6-21 Información del croquis antes del proceso automático de depuración

Se procede a ejecutar el módulo con los archivos de entrada correspondientes y como salida el

archivo final.svg.

Figura 6-22 Ejecución del módulo de edición automática

Capítulo 6 Pruebas

127

Comparando con la información que se encontraba antes del proceso de edición automática

podemos notar la ausencia de “info_dad_pb_Depto_RecFinan” dado que no tiene ninguna

información solicitada por el archivo de recomendación.

Figura 6-23 Información adicional después del proceso de edición automática

También se observa que a los elementos que conservaron su información adicional se les

agregó un elemento de animación.

Figura 6-24 Código de animación agregado por el proceso de edición automática

Capítulo 6 Pruebas

128

Bitácora de prueba VSA-04-01.

Descripción: Ésta bitácora corresponde al procedimiento de prueba VSA-03-01 definido en el


En esta prueba se verifica que la información asociada a los elementos SVG de un croquis sea

desplegada de manera adecuada en el visualizador SVG para dispositivos móviles con

plataforma Android.

Dentro del croquis se encuentra la siguiente información:

Tabla 6-3Información restante después del proceso de edición automática





dcc_pa_cubo_10 Cubículo 10, Juan Gabriel González, Impresora, Multifuncional,


Capítulo 6 Pruebas

129

Al abrir el croquis en el visualizador y ver las capas se puede observar que se encuentran las 2

capas definidas en el croquis.

Figura 6-25 Capas en la interfaz gráfica del visualizador

Haciendo la comparativa se aprecia en la primera serie de imágenes la animación existente

para el elemento “dcc_pb_Aula_2”, y al seleccionar dicho elemento en la tercera imagen se

aprecia la información adicional que corresponde a la descrita en la tabla anterior.

Figura 6-26 Efecto de animación e información del primer elemento

Capítulo 6 Pruebas

130

De la misma manera para la capa 2, se aprecia el efecto de animación sobre el elemento svg_6

y la información adicional correspondiente a la tabla anterior.

Figura 6-27 Efecto de animación e información del segundo elemento

Capítulo 7 Conclusiones.

Capítulo 7 Conclusiones

132

7.1 Conclusiones.

Como resultado de este trabajo de tesis se obtienen tres prototipos: una aplicación web para la

creación y edición de mapas en formato SVG con anotaciones semánticas, un módulo de

edición automática de mapas; que se encarga de remover anotaciones semánticas innecesarias,

y el visualizador de mapas SVG para dispositivos Android. Dichos prototipos proveen parte de

las bases para el subsistema de localización en exteriores e interiores de un sistema de

recomendación contextual para organizaciones.

Así mismo se creó una ontología para la infraestructura de una organización, ésta ontología

está planeada para ser genérica y representar cualquier tipo de organización y no solo a las

instituciones de educación superior, empresas de tecnologías de la información y

comunicación y gobierno.

Se corrobora lo planteado en el trabajo de [Chang 2003], de empotrar semántica de un

dominio a elementos gráficos de SVG, mediante la herramienta para la creación y edición de

mapas que nos devuelve un mapa en formato SVG Tiny que contiene información acerca de

los recursos humanos y materiales de una organización en particular, salida verificable

mediante el visualizador de mapas SVG para dispositivos Android; que permite acceder a la

información contenida en el mapa.

Con el módulo de edición automática se pretende disminuir el costo de transferencia y

procesamiento de carga desde el servidor hasta el visualizador en el dispositivo móvil,

mediante la reducción del tamaño del archivo, eliminando información que no le es pertinente

a un usuario en determinado momento.

El uso de SVG como formato de imagen para los mapas proporciona independencia al

dispositivo móvil, una vez que ya se encuentra cargado en el visualizador, dado que no

requiere de consultas a fuentes externas de datos para acceder a la información de la

organización que representa ya que esta se encuentra dentro del mismo archivo.

Con esto se establecen las bases para establecer un sistema que sea capaz de proporcionar

información de las ubicaciones de cualquier tipo de instalaciones al proveer los módulos d

software básicos para la integración de la información existente de una organización con la

representación gráfica de la misma.


133

7.2 Aportaciones.

El desarrollo de este trabajo provee las siguientes aportaciones prácticas:

Con la ontología de infraestructura se contribuye a la red de ontologías desarrolladas

para el trabajo de [González 2012].

El proceso de población de información al mapa permite que una persona que no

necesariamente tiene conocimientos de diseño gráfico o más aún del formato SVG,

pueda realizar la operación el trabajo sin problemas.

El módulo de edición automática deja las clases necesarias para ser invocadas y

realizar el proceso, porque lo que están listas para el proceso de integración.

El visualizador de mapas SVG en Android provee la explotación de la información

tratada en las herramientas anteriores y es funcional en plataformas versión 2.x.

7.3 Trabajos futuros.

Dadas las herramientas desarrolladas en este trabajo existen diferentes trabajos que pueden

extender la funcionalidad:

Es posible extender la aplicación para la creación y edición de mapas, a manera que

permita que una misma persona se encargue del dibujo del mapa y el poblado de

información de sus elementos.

También sería adecuado implementar un proceso de altas, bajas y cambios a la

información del almacenamiento de tripletas dentro de la aplicación web.

La plantilla para la información adicional asociable a un mapa es solo una base, gracias

a la extensibilidad del XML es posible que se expanda la información que se asocie a

los elementos del mapa, aunque esto implica extender de igual manera las herramientas

que interactúan con esta información.

El visualizador SVG utilizó la librería TinyLine, la cual provee una API para Android

y J2ME, por lo que es factible realizar implementaciones del visualizador para otras

plataformas.


134

El acoplamiento de estas herramientas con los trabajos de [Arjona 2009], [González

2012] e [Yris 2012] realizados dentro del Centro Nacional de Investigación y

Desarrollo Tecnológico

135

Referencias.

[ADA 1994] U.S. Department of Justice, “ADA Standards for Accessible

Design”, 1994

[Anagnostopoulos 2005] Anagnostopoulos C. & Tsetsos V. & Kikiras P. &

Hadjiefthymiades S., “OntoNav: A semantic indoor navigation

system”, 1st Workshop on Semantics in Mobile Environments,

2005.

[Android 2011] Android developers, “What is Android?”, Guía de desarrollo,

recuperado el 21 de septiembre de 2011 de

<http://developer.android.com/guide/basics/what-is-android.html>

[Arjona 2009] Arjona I., “Servicios de localización conscientes del contexto

aplicando perfiles de movilidad y tecnologías de localización

heterogéneas”, Tesis de Maestría, CENIDET, México, 2009

[Chang 2003] Chang Y. & Chuang T., “Embedding domain semantics in SVG”,

SVG Open 2003 Conference and Exhibition, Vancouver, Canada,

2003

[Chen 2003] Chen, H. & Finin, T. & Anupam J., “An ontology for context-

aware pervasive computing environments”, The Knowledge

Engineering Review,Vol. 18(3), 2003, pp 197-207, ISSN 0269-

8889, Cambridge University Press.

[Dudas 2009] Dudas, P.M. & Ghafourian, M. & Karimi, H.A., “ONALIN:

ontology and algorithm for indoor routing”, Tenth International

Conference on Mobile Data Management: Systems, Services and

Middleware, 2009, pp 720-725.

[Ehrig 2006] Ehrig M 2006, Ontology aligment: Bridging the semantic gap,

Springer, ISBN / ASIN: 038732805X

[Fernández 1997] Fernández M, Gómez A & Juristo, N 1997 "Methontology: from

ontological art towards ontological engineering", "Proc.

136

Symposium on Ontological Engineering of AAAI"

[González 2012] González, N. “Sistema de recomendación contextual basado en

ontologías para ambientes organizacionales y de usuario en

entornos de cómputo móvil”, Tesis de maestría en proceso,

CENIDET, México, 2010.

[Gruber 2009] Gruber T., “Ontology”, Artículo en Encyclopedia of Database

Systems, Ling L. & Özsu T., Springer-Verlag, 2009.

[GSM Association 2003] GSM Association, Location–Based Services. Permanent Reference

Document: SE.23, 2003, recuperado el 12 de abril de 2010 de

<http://gsmworld.com/documents/se23.pdf>

[Hu 2004] Hu, H. & Lee D., “Semantic modeling for location navigation in

mobile environment”, Proceedings of the IEEE International

Conference on Mobile Data Management, 2004, pp 52-61, ISBN

0-7695-2070-7

[IES_EP 2011] IES Eduardo Pondal, “Imagen digital”, Departamento de

Tecnoloxía, recuperado el 23 de septiembre de 2011 de

<http://centros.edu.xunta.es/ieseduardopondal/tecnoweb/temas_inf

ormatica/imagendigital.pdf>

[Jena 2011] Jena, “Home”, Jena - A semantic web framework for Java,


<http://jena.sourceforge.net/index.html>

[Jena2 2011] Jena, “Persistence subsystems for Jena”, Jena documentation,


<http://jena.sourceforge.net/documentation.html>

[Kottahachchi 2005] Kottahachchi, B. & Laddaga, R. & Look, G., “LAIR: location

awareness information representation”, Proceedings of the 9th

WSEAS International Conference on Computers, 2005, pp 1-6,

ISBN 960-8457-29-7.

[Kuipers 1977] Kuipers, B., “Representing Knowledge of Large-scale Space”,

Reporte técnico, Massachusetts Institute of Technology, MIT

137

AI/TR418.

[Mor 2007] Mor Y, “Techniques for binding scalable vector graphics to

associated information”, No. Patente 7210095, Estados Unidos de

América, 2007

[Noy 2005] Noy, N. & McGuinness D, “Desarrollo de ontologías 101: guía

para crear tu primera ontología”, Standford University, 2005.

[OPA 2011] Open Handset Alliance, “Overview”, recuperado el 21 de

septiembre de 2011 de

<http://www.openhandsetalliance.com/oha_overview.html>

[Quiñonez 2008] Quiñonez P., “Gateway SMS Pull para servicios basados en

localización con arquitectura de servicios Web”, Tesis de

Maestría, CENIDET, México, 2008.

[Ruiz 2007] Ruiz L., “API SMS para el procesamiento de consultas

georeferenciadas y no georeferenciadas”, Tesis de Maestría,

CENIDET, México, 2007

[Schmitt 2005] Schmitt, C. & Kaufmann O., “Indoor navigation with SVG”, SVG

Open 2005 Conference & Exhibition, Enschede, Países Bajos,

2005.

[SVG 2008] W3C, Scalable Vector Grpahics (SVG) 1.2 Specification, 2008,

recuperado el 26 de noviembre de 2010 de

<http://www.w3.org/TR/SVGTiny12/>

[SVGM 2003] W3C, Mobile SVG Profiles: SVG Tiny and SVG Basic, 2003,

recuperado el 26 de noviembre de 2010 de

<http://www.w3.org/TR/SVGMobile/>

[TinyLine 2011] TinyLine, “TinyLine SVG”, recuperado el 23 de septiembre de

2011 de < http://www.tinyline.com/svgt/index.html>

[Vargas 2011] Vargas R., Modelo colaborativo para la integración de sistemas,

Tesis de Doctorado en proceso, CENIDET, México, 2010

[Wood 2011] Wood K., “jQuery SVG”, recuperado el 23 de septiembre de 2011

de <http://keith-wood.name/svg.html>

138

[Yris 2012] Yris, M., “API para servicios de localización basada en tecnología

RFID, QRCode, WiFi y Bluetooth”, Tesis de maestría en proceso,

CENIDET, México, 2010.

Anexos

Anexos

140

Anexo A1. Plan de pruebas – PP01

Introducción

El presente documento se apega a los lineamientos establecidos en el estándar IEEE829-1998

para la documentación de pruebas de software.

El plan de pruebas cubre la totalidad del software desarrollado en el trabajo de tesis al cual

está asociado el nombre: Generación y explotación de mapas semánticos de instalaciones

organizacionales mediante el uso de ontologías y detalla las actividades necesarias para

preparar y realizar las pruebas.

Elementos a evaluar

Herramienta para la generación y edición de croquis haciendo uso de ontologías.

(HGC)

Módulo de edición automática de croquis. (MEA)

Visualizador SVG para plataforma Android. (VSA)

Características a evaluar

La siguiente lista describe las características que se evaluarán en el plan de pruebas:

Número de diseño de prueba Descripción

HGC-01-01 Creación de croquis con información asociada.

HGC-01-02 Eliminación y reemplazo de información asociada.

MEA-01-01 Depuración de la información asociada al croquis.

VSA-01-01 Despliegue de información adicional del croquis.

Características sin evaluar

Cualquier herramienta adicional desarrollada y que ayude en la ejecución de las pruebas.

Enfoque

A continuación se enlista el enfoque a utilizar para cada prueba:

Anexos

141

HGC-01-01. Verificar que a partir de un croquis sin información adicional, el croquis

generado contenga toda la información asociada a las figuras después de un proceso de

inserción dentro de la aplicación.

HCG-01-02. Verificar que un croquis que previamente contenga información asociada,

quede solo la información correspondiente después de un proceso de eliminación y

reasignación de información dentro de la aplicación.

MEA-01-01. Obtener una copia del archivo que solo contenga la información asociada

requerida por el archivo de recomendaciones.

VSA-01-01. Observar que la información asociada a los elementos del croquis se

despliegue en la pantalla del dispositivo móvil.

Criterios de aprobación/fallo.

Se dará por aprobada una prueba cuando se cumplan con las salidas esperadas descritas en los

casos de pruebas y como fallida en caso contrario.

Pruebas entregables

Los siguientes documentos serán presentados después de realizar las pruebas:

Especificaciones de diseño de pruebas.

Especificaciones de casos de pruebas.

Reporte resumen de pruebas.

Tareas de prueba

Tarea Tarea precedente Fecha de

terminación

(1) Preparar plan de pruebas. Completar desarrollo de las

herramientas a evaluar

15-05-2011

(2) Preparar especificaciones de diseño de

pruebas.

Tarea (1) 16-05-2011

(3) Preparar especificaciones de casos de

prueba.

Tarea (2) 17-05-2011

Anexos

142

(4) Ejecución de pruebas. Tarea (3) 22-05-2011

(5) Resolver incidentes. Tarea (4) 29-05-2011

(6) Realizar (4) y (5) hasta que todas las

pruebas estén aprobadas.

Tarea (5) 05-06-2011

(7) Escribir el reporte resumen de pruebas. Tarea (6) 08-06-2011

Requisitos ambientales

Infraestructura de red inalámbrica.

Servidor web y de aplicaciones web.

PC o Laptop con resolución mínima de pantalla de 1366 x 768 pixeles, navegador con

soporte JavaScript.

Dispositivo móvil con plataforma Android 2.1 o superior.

Responsabilidades

Todas las pruebas están asignadas al autor de la tesis, el ISC. Ricardo Estrada Peláez

Nomenclatura

Los elementos contenidos en el plan de pruebas se apegan a la siguiente nomenclatura XXX-

YY-ZZ, donde:

XXX corresponde a las letras que definen el prototipo a evaluar. (HGC, MEA, VSA).

YY número que indica si es: 01 es un diseño de prueba, 02 es un caso de prueba, 03 es

un procedimiento de prueba y 04 es una bitácora de prueba.

ZZ número consecutivo.

Aprobación

Director de Tesis – Dra. Azucena Montes Rendón

____________________

Codirector de Tesis – Dr. Juan Gabriel González Serna

____________________

Autor de Tesis – ISC. Ricardo Estrada Peláez ____________________

Anexos

143

Especificación de diseño de pruebas - HGC-01-01

Esta especificación se relaciona con el plan de pruebas PP-01.

Elementos a evaluar

(1) Archivo de entrada sin información adicional.

(2) Asociación de información a los elementos del mapa.

(3) Archivo de salida con la información adicional seleccionada en (2).

Enfoque

En (1) se observa la estructura del archivo, para corroborar que no existen datos adicionales.

En (2) se observa y registra la correspondencia de los pares (elemento SVG, información

adicional) correspondientes para su verificación en el punto (3).

En (3) se observa la estructura del archivo, verificación que se encuentre la información

adicional correspondiente a cada par registrado en el punto (2).

Identificación de pruebas

Caso Caso de prueba

Archivo de entrada sin información adicional. HGC-02-01

Asociación de información a los elementos del mapa. HGC-02-02

Archivo de salida con la información adicional seleccionada. HGC-02-03


Anexos

144

Cada elemento debe pasar sus casos de prueba para considerarse como aprobada esta prueba.

Especificación de diseño de pruebas - HGC-01-02


Elementos a evaluar

(1) Información asociada inicialmente en el croquis.

(2) Eliminación y reasignación de información adicional a los elementos SVG.

(3) Archivo de salida conteniendo solo la información correspondiente en (2).

Enfoque

En (1) se obtiene la referencia para observar la diferencia en la información contenida en el

archivo de salida con la información original del archivo.

En (2) se registran los cambios hechos dentro de la aplicación, para restarlos a los tomados en

el punto (1).

En (3) se observa que en el archivo de salida posea únicamente la información que se deseó

conservar.


Caso Caso de prueba

Archivo de entrada con información adicional. HGC-02-04

Eliminación y reasignación de información a los elementos SVG HGC-02-05

Archivo de salida con la información adicional correspondiente. HGC-02-06



Especificación de diseño de pruebas – MEA-01-01


Anexos

145

Elementos a evaluar

(1) Copia modificada del croquis.

Enfoque

En (1) se busca la correspondencia de la información adicional restante contenida en el

archivo de salida con la información solicitada en el archivo de recomendación.


Caso Caso de prueba

Copia modificada del croquis MEA-02-01



Especificación de diseño de pruebas – VSA-01-01


Elementos a evaluar

(1) Información desplegada en pantalla.

Enfoque

En (1) se busca la correspondencia de lo mostrado en la pantalla del visualizador con el

contenido del croquis.


Caso Caso de prueba

Información desplegada en pantalla. VSA-02-01



Anexos

146

Especificación de caso de prueba – HGC-02-01

Elementos a evaluar

Archivo de entrada sin información adicional. Este caso verifica que el archivo SVG a utilizar

no contenga información extra a la definida en la especificación SVG.

Especificaciones de entrada

(1) Archivo SVG.

Especificaciones de salida

Lista de verificación de elementos.

Lista de identificadores de elementos SVG.


Elementos a evaluar

Información asociada a los elementos SVG. Este caso registra que información va a ser

agregada al croquis para su posterior verificación.


(1) Archivo SVG.

(2) Instancias obtenidas del repositorio de tripletas.

(3) Operaciones de asignación.


Lista de pares (identificador, información) de las operaciones de asignación realizadas

en la aplicación.


Anexos

147

Elementos a evaluar

Archivo de salida. Este caso verifica que la información adicional que se escribe en el mapa

esté completa comparándola con la información que fue asociada en el proceso de asignación

de la aplicación.


(1) Lista de pares (identificador, información)

(2) Archivo SVG de salida.


Lista de verificación completa de equivalencia entre (1) y (2).


Elementos a evaluar

Archivo de entrada con información adicional. Este caso verifica que el archivo SVG a utilizar

contenga información adicional que fue asignada previamente por la aplicación.


(1) Archivo SVG.


Lista de pares (identificador, información).


Elementos a evaluar

Anexos

148

Eliminación y reasignación de información adicional a los elementos SVG. Este caso registra

que información va a ser eliminada del croquis o sobre cuales elementos se va a cambiar su

información asociada, esto para su posterior verificación en el archivo de salida.


(1) Operaciones de eliminación y modificación.


Lista de pares (identificador, información) de las operaciones de eliminación o

reasignación realizadas en la aplicación.


Elementos a evaluar

Archivo de salida. Este caso verifica que la información adicional que se escribe en el mapa

esté acorde a la información que modificada en el proceso de eliminación y reasignación de la

aplicación.


(1) Lista de pares (identificador, información) originales.

(2) Lista de pares (identificador, información) modificados en la aplicación.

(3) Archivo SVG de salida.


Lista (1) modificada con respecto a (2).

Lista de pares (identificador, información) proveniente del croquis.

Especificación de caso de prueba – MEA-02-01

Elementos a evaluar

Anexos

149

Copias modificada del croquis. Este caso verifica que la información adicional contenida en la

copia del croquis sea solamente aquella que se solicitó en el archivo de recomendación y que

los lugares necesarios tengan su animación.


(1) Copia modificada del croquis.

(2) Lista de lugares a marcar.

(3) Lista de información de recomendaciones.


Lista de verificación completa de correspondencia entre (1) y (2).

Lista de verificación completa de correspondencia entre (1) y (3).

Especificación de caso de prueba – VSA-02-01

Elementos a evaluar

Información desplegada en pantalla. Este caso verifica que la información acerca de un

elemento del croquis que se despliega en el visualizador sea la correspondiente a la que se

encuentra almacenada en el archivo.


(1) Datos de pantalla.

(2) Copia modificada de croquis.


Una lista de verificación de correspondencia completa.

Especificación de procedimiento de prueba – HGC-03-01

Anexos

150

Este procedimiento describe los pasos necesarios para la prueba especificada en el diseño de

prueba “Creación de croquis con información asociada” (HGC-01-01). El procedimiento

plantea la ejecución del caso de prueba descrito en HGC-02-01.

Requisitos especiales

Ninguno.

Pasos del procedimiento

Inicialización

(1) Elegir el croquis que se va a utilizar.

Proceso

(1) Abrir el archivo con un editor de texto.

(2) Verificar que no exista en la definición de la cabecera SVG, ningún nombre

de espacios ajeno al uso de SVG.

(3) Verificar que no exista información ajena a SVG en alguna etiqueta <defs>

que se encuentre.

(4) Crear una lista de los valores de todos los atributos “id” encontrados en el

archivo.

Medición

(1) Cumplimento de los puntos (2) y (3) de la sección Proceso, si la condición

se cumple se pasa la prueba.

Conclusión

(1) Se cierra el editor de texto.

(2) Conservar la lista de los atributos extraídos.





Anexos

151

El procedimiento utilizará la herramienta para la generación y edición de croquis haciendo uso

de ontologías (HGC).


Para la ejecución de este procedimiento es necesario que exista al menos una ontología

organizacional en el almacén de tripletas y que contenga al menos información (atributos y

relaciones) de personas, recursos y espacios.


Inicialización

(1) Cargar el croquis a utilizar.

Proceso

(1) Seleccionar el croquis cargado y la organización a la que se le va a

adjudicar.

(2) Elegir el elemento SVG por medio de su identificador y la información que

se le va a asociar

(3) Dar la orden de asociar la información.

(4) Registrar en la lista el par (identificador, información).

Medición

(1) Cada asociación se debe reflejar en la interfaz de la aplicación, si se cumple

esto se pasa la prueba.

Conclusión

(1) Se conserva la lista registrada en el paso (4) de la etapa Proceso.





Anexos

152




Para la ejecución de este procedimiento es necesario que exista al menos un croquis al cual ya

se le haya asignado información adicional.


Inicialización

(1) Solicitar a la aplicación que genere el croquis con información adicional.

(2) Abrir el archivo en un editor de texto.

Proceso

(1) Utilizar la lista de pares (identificador, información) y verificar lo siguiente

en el archivo.

(2) Por cada identificador de la lista de pares, ubicar su elemento SVG

correspondiente y verificar que contenga el atributo “xlink:href”.

(3) Verificar que cada atributo “xlink:href” encontrado tenga información

correspondiente dentro de una etiqueta <defs>.

(4) Si los pasos (2) y (3) se cumplen, eliminar de la lista de pares la entrada

correspondiente.

Medición

(1) Si la lista de pares termina sin elementos, se pasa la prueba.

Conclusión




prueba “Eliminación y reemplazo de información asociada” (HGC-01-02). El procedimiento


Anexos

153


Para la ejecución de este procedimiento es necesario que exista al menos un croquis al cual ya

se le haya asignado información adicional.


Inicialización

(1) Elegir el croquis que se va a utilizar.

Proceso

(1) Abrir el archivo con un editor de texto.

(2) Crear una lista de pares (identificador, información) del croquis.

Medición

(1) Si la lista tiene al menos un elemento se pasa la prueba.

Conclusión









Para la ejecución de este procedimiento es necesario que exista al menos una ontología

organizacional en el almacén de tripletas y que contenga al menos información (atributos y

relaciones) de personas, recursos y espacios.


Anexos

154

Inicialización

(1) Se elige el croquis y la organización correspondiente a utilizar.

Proceso

(1) Elegir un elemento SVG por medio de su identificador, desasociar la

información y registrar el par (identificador, información).

(2) Elegir un elemento SVG por medio de su identificador, asociarle nueva

información y registrar el par (identificador, información).

(3) Realizar los pasos (1) y (2) para cualquier número de elementos.

Medición

(1) Cada asociación o eliminación se debe reflejar en la interfaz de la

aplicación, si se cumple esto se pasa la prueba.

Conclusión

(1) Se conserva la lista registrada de los pasos (1 y 2) de a etapa Proceso.








Para la ejecución de este procedimiento es necesario que exista al menos un croquis al cual

haya pasado por la prueba HGC-02-05.


Inicialización

(1) Solicitar a la aplicación que genere el croquis con información adicional.

(2) Abrir el archivo en un editor de texto.

Anexos

155

Proceso

(1) Utilizar la lista de pares (identificador, información) obtenida de la prueba

HGC-02-05 y verificar lo siguiente en el archivo.

(2) Verificar que cada nodo de información se encuentre dentro de la lista de

pares y eliminar la entrada de la lista

Medición

(1) Si la lista de pares termina sin elementos, se pasa la prueba.

Conclusión


Especificación de procedimiento de prueba – MEA-03-01


prueba “Depuración de la información asociada al croquis” (MEA-01-01). El procedimiento

plantea la ejecución del caso de prueba descrito en MEA-02-01.

El procedimiento utilizará el módulo de edición automática de croquis (MEA).


Para la ejecución de este procedimiento es necesario que exista al menos un croquis que ya

posea información adicional.


Inicialización

(1) Abrir el archivo de recomendación y extraer la información que

corresponde a la parte de visualización en el croquis.

Proceso

(1) Introducir la lista de recomendaciones y el croquis al módulo

(2) Recibir el croquis modificado.

(3) Realizar un segunda lista de pares (identificador, información) a partir del

croquis modificado.

Anexos

156

(4) Verificar la correspondencia de la información en la nueva lista con la

obtenida en (1) del proceso de Inicialización.

Medición

(1) Si existen elementos con información que no esté incluida en (1) del

proceso de Inicialización, la prueba falla, en caso contrario se aprueba.

Conclusión

(1) Cerrar el archivo de recomendación.

Especificación de procedimiento de prueba – VSA-03-01


prueba “Despliegue de información adicional” (VSA-01-01). El procedimiento plantea la

ejecución del caso de prueba descrito en VSA-02-01.

El procedimiento utilizará el visualizador SVG para plataforma Android (VSA).


Debe existir un croquis con información adicional.


Inicialización

(1) Abrir el croquis en el visualizador.

(2) Seleccionar la opción de visualizar información en el dispositivo.

(3) Realizar una lista de la información adicional que se encuentra en el

croquis.

Proceso

(1) Dar clic a algún elemento gráfico que se conozca tenga información.

(2) Observar la información que se despliega en pantalla.

(3) Por cada elemento del croquis, marcar en la lista (3) del proceso de

Inicialización, que información se despliega si esta existe.

Medición

Anexos

157

(1) Si la lista está completamente marcada, es decir, toda la información se

desplegó en pantalla, se pasa la prueba.

Conclusión

(1) Se cierra el visualizador.

Anexo A2. Formato del archivo de recomendaciones XML

El archivo de recomendaciones que recibe el módulo de edición automática de croquis debe la

estructura que se presenta en el código 1. Donde es de particular interés las etiquetas conjunto

con el valor “Acciones” en su atributo “tipo” y que su etiqueta idAccion contenga un valor

igual a 1.

Código 4. Ejemplo de archivo XML de recomendaciones.

<?xml version="1.0" ?>

<valoraciones id_usuario="user1" time="9:22:30" date="2011-03-09">

<conjunto tipo="Personas">

<idElemento>1</idElemento>

<Elemento>Juan Gabriel Gonzalez Serna</Elemento>

<Calificacion>1</Calificacion>

<Disponibilidad>Disponible</Disponibilidad>

</conjunto>

<conjunto tipo="Objetos de Conocimiento">


<Elemento>Esquema adaptativo para la gestión de movilidad en sistemas cliente/servidor a

través de internet</Elemento>

<Calificacion>0.7</Calificacion>


</conjunto>

<conjunto tipo="Lugares">


<Elemento>Laboratorio de Sistemas Distribuidos</Elemento>



</conjunto>

<conjunto tipo="Competencias">


<Elemento>Residencias Profecionales</Elemento>



Anexos

158

</conjunto>

<conjunto tipo="Recursos">


<Elemento>HTC Dsire</Elemento>



</conjunto>

<conjunto tipo="Actividades">


<Elemento>Seminario SD</Elemento>



</conjunto>

<conjunto tipo="Acciones">

<idAccion>1</idAccion>


<tipoElemento>Personas</tipoElemento>

</conjunto>




<tipoElemento>Recursos</tipoElemento>

</conjunto>




<tipoElemento>Personas</tipoElemento>

</conjunto>

</valoraciones>

Anexo A3. Formato del archivo SVG

El archivo SVG con el que se trabaja posee una variante con respecto a lo descrito en la

especificación de SVG Tiny 1.2, en donde colocamos dentro de la etiqueta <defs> de SVG

toda la información que no corresponde propiamente a la especificación, esto es, la

información relacionada a las figuras trazadas.

La información ahí contenida es el identificador que liga a la figura con la información, el

nombre del lugar, el tipo de funciones que puede realizarse en él, las personas que están

encargadas del lugar o que normalmente pueden ser localizadas en él y los recursos asociados

al lugar.

Anexos

159

Las restricciones necesarias sobre los elementos de SVG para el correcto funcionamiento del

visualizador son:

En la etiqueta SVG, tener el atributo viewBox presente.

Los elementos <g> que quieran ser considerados como capas deben de tener el atributo

“display” declarado explícitamente, así como un atributo “id”.

Solo puede haber una capa que tenga el valor “inline” en su atributo “display” en un

momento dado, todos los demás deberán tener el valor de “none”.

Código 5. Ejemplo de archivo SVG.


<svg width="640" height="640" viewBox="0 0 640 640" version="1.2" baseProfile="tiny"

xmlns="http://www.w3.org/2000/svg"

xmlns:guide="http://www.cenidet.edu.mx"

xmlns:xlink="http://www.w3.org/1999/xlink">

<defs>

<guide:place id="info_dcc_pb_lab_sd">

<guide:name value="Laboratorio de Sistemas Distribuidos" />

<guide:functions>

<guide:function value ="Laboratorio" />

<guide:function value ="Prácticas" />

<guide:function value ="Auditorio" />

</guide:functions>

<guide:persons>

<guide:person id="1" qrcode="123456789" rfid="123456789" fullName="Everardo" />

<guide:person id="2" qrcode="987654321" rfid="987654321" fullName="Felipe" />

<guide:person id="3" qrcode="543216789" rfid="543216789" fullName="Ricardo" />

</guide:persons>

<guide:resources>

<guide:resource rfid="666666666" name="Servidor SD" />

</guide:resources>

</guide:place>

</defs>



</svg>

Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de...

Technology

Transcript of Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de...