Centro Nacional de Investigación y Desarrollo Tecnológico20Matilde%… · Resumen Los sitios Web...
Transcript of Centro Nacional de Investigación y Desarrollo Tecnológico20Matilde%… · Resumen Los sitios Web...
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Metodología para Definir una Arquitectura de Sitios Web Basada en Diseño de Ontologías
presentada por
Matilde Baños Nolasco Ing. en Sistemas Computacionales por el I. T. de Minatitlán
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dr. José Antonio Zárate Marceleño
Co-Director de tesis:
Dr. Juan Gabriel González Serna
Jurado: M.C. Mario Guillén Rodríguez – Presidente
Dr. José Antonio Zárate Marceleño– Secretario M.C. Reynaldo Alanís Cantú – Vocal
M.C. Hugo Estrada Esquivel – Vocal Suplente
Cuernavaca, Morelos, México. 11 de septiembre de 2008
“Hay hombres que luchan un día y son buenos. Hay otros que luchan un año y son mejores.
Hay quienes luchan muchos años, y son muy buenos. Pero hay los que luchan toda la vida, esos son los imprescindibles.”
Bertolt Brecht
Dedicatoria
A mis padres: A mi padre. Por enseñarme que nada en la vida es fácil de alcanzar, pero que el trabajo duro siempre recibe recompensa. De usted aprendí que es importante ser estricto y justo, sin dejar de ser flexible. Que se debe mantener la dignidad a toda costa y que nunca se debe negar la
mano a quien la extiende buscando ayuda. Aunque no está físicamente, estará siempre en mi corazón y en cada logro de mi vida.
A mi madre. Gracias por tu fortaleza y tu entereza a lo largo de los años. Por los enormes
sacrificios con los que has sacado adelante a nuestra familia. Por demostrarme que ni siquiera los impedimentos físicos son un pretexto para dejarse vencer y que no existe sentimiento que
engrandezca tanto al hombre como el amor sin medida.
A mi hermana: Por demostrar siempre tu amor, con palabras y con acciones. Tu expresividad es una
cualidad de la que yo carezco, pero ha sido siempre un puente para mantener la unión en los eslabones más débiles de nuestra relación familiar.
Has estado siempre ahí para cuidarme cuando era necesario y asumir tu papel. Gracias por todo.
A mi abuela: Por ser una segunda madre para mí. Gracias por los cuidados y regaños que todavía
recibimos. Por las oraciones en mi nombre y las bendiciones diarias cada mañana y cada noche. Con el paso del tiempo he aprendido el valor de tenerla todavía conmigo, como un
tesoro de historias y experiencias y, más que nada, de amor.
Agradecimiento
A CONACYT por el apoyo económico otorgado para la realización de este proyecto.
A mi director de tesis, Dr. José Antonio Zárate Marceleño, por brindarme su ayuda y consejo en el desarrollo de esta investigación, por su profesionalismo y su calidad humana. A mi codirector, Dr. Juan Gabriel González Serna, a quien admiro por su dedicación en el trabajo.
A los revisores de esta tesis de investigación, M.C. Hugo Estrada Esquivel, M.C. Mario Guillén y M.C. Reynaldo Alanís Cantú, por su disposición, sus valiosos comentarios y observaciones.
Al Centro Nacional de Investigación y Desarrollo Tecnológico y a todo el personal que labora en esta institución. En especial al M.C. Hugo Estada Esquivel, quien confió siempre en mis capacidades y me brindó su amistad sincera. A la Dra. Azucena Montes Rendón y al Dr. Máximo López Sánchez.
A Eduardo, por tu cariño constante y sincero. Mil gracias por la oportunidad de conocer a un hombre maravilloso de quien solo puedo expresarme de la mejor manera. Gracias también por creer en mí.
Al Lic. Andrés Díaz Elizalde, por ser siempre un valioso ejemplo y haber encontrado en su amistad una guía moral que me ha ayudado a madurar en muchos aspectos de mi vida.
A mis amigos: María Magdalena, Yazmin, Adriana, Abdiel, Hugo Alberto, Christian Emmanuel y Cristian Servelio. Por acompañarme en los momentos de incertidumbre y en las alegrías de todos los días.
A mis amigos del cenidet: Jorge Alberto, por ser una persona maravillosa y amable que con algunas reservas me compartió su sentir. Edgar Omar, por los consejos a distancia y el apoyo incondicional, espero que podamos contar siempre el uno con el otro. Ismael Rafael, por tu carácter noble y tu actitud desinteresada, y en especial a Jesús Guillermo por tu compañía y contagiosa fortaleza de espíritu cuando más me hizo falta, por ser mi amigo a pesar de todo siempre tendrás un lugar especial en mi corazón.
Para mis tíos Raymundo, Gloria, Roberto y Rosalía, quienes están siempre al pendiente, a pesar de la distancia. A todos, mil gracias.
Matilde Baños Nolasco.
Resumen
Los sitios Web son un recurso para distribuir información, utilizados para distintos propósitos, como: informativos, transaccionales, de comunidad, entretenimiento, comerciales, de gobierno, de educación, personales, entre otros.
Por su naturaleza, los sitios Web, poseen estructuras difíciles de entender, debido a la multiplicidad de sus enlaces y la falta de semántica en éstos.
El uso de enlaces entre páginas sin entender el significado semántico de lo que relacionan, genera una estructura bajo el esquema de organización de “Web pura” [Powell 2002]. Este tipo de esquema resta claridad a la estructura. Diversos estudios como los realizados por el IHMC demuestran que el aprendizaje se basa en el uso de relaciones entre conceptos. Es por ello que resulta necesario agregar semántica que ayude a entender cómo están relacionados entre sí los elementos que conforman el sitio Web.
Se han realizado análisis de diferentes enfoques para la búsqueda de la definición
formal de las relaciones. Algunos de estos enfoques son: las relaciones semánticas definidas en la lingüística (en este trabajo se hizo hincapié en una de ellas, la meronimia) y propiedades de UML.
El presente trabajo describe una metodología que utiliza conceptos de diseño de
ontologías para crear estructuras. La metodología propuesta muestra que la construcción del sitio implica el uso de un conjunto de relaciones entre sus elementos (páginas, archivos multimedia, entre otros), donde las relaciones corresponden a los enlaces. Con esto se intenta proporcionar una solución a la falta de semántica de la arquitectura de los sitios Web. Para llevar a cabo esta tarea se siguió un proceso de análisis sobre un dominio específico. Posteriormente se determinaron patrones de construcción que ayudaron a obtener conceptos propios del dominio para conformar una jerarquía de clases. Se establecieron relaciones entre los conceptos, una tipificación de dichas relaciones, siendo ésta la principal aportación de este trabajo y además, se implementó un editor de sitios Web basado en los resultados del análisis anterior.
Abstract
Websites are a resource for distributing information, used for different purposes such as: informative, transactional, community, entertainment, business, government, educational, personal ones, among others. Because of its nature, Websites, have structures difficult to understand, due to the multiplicity of their links and the lack of semantics in these.
The use of links among pages without understanding the semantic meaning of what
they relate generates a structure under the "pure web" organization scheme [Powell 2002]. This type of scheme reduces clarity to the structure. Several studies, such as the ones coming from the IHMC’s, show that the learning process is based in the use of relations among concepts. Therefore, is necessary to add semantics to the Web site structure such that they help to understand how the elements forming it are interrelated among them. There have been done analyses of different approaches for the searching of formal definition of the relations. Some of these approaches are: the semantic relations, mereology characteristics and UML properties.
The present work describes a methodology that uses ontology design concepts in
order to create structures. The proposed methodology shows that the construction of the site implies the use of a set of relations among its elements (pages, multimedia files, and others), where relations fit to links. This is an attempt to provide a solution to the lack of semantics in Websites architecture.
To carry out this task an analysis process was followed over a specific domain. Afterwards construction patterns were determined that help to obtain concepts of the domain to conform a hierarchy of classes. Relations among concepts were established, a categorization of such relations, being this the principal contribution of this work, and it was also developed a Website editor based on the results of the previous analysis.
Página i
Índice de contenido CAPÍTULO 1. INTRODUCCIÓN ..................................................................................................................... 1
1.1. ANTECEDENTES .......................................................................................................................................... 2 1.2. DESCRIPCIÓN DEL PROBLEMA ........................................................................................................................ 3 1.3. OBJETIVO.................................................................................................................................................. 3 1.4. JUSTIFICACIÓN ........................................................................................................................................... 4 1.5. ALCANCES ................................................................................................................................................. 5 1.6. LIMITACIONES ............................................................................................................................................ 5 1.7. BENEFICIOS ............................................................................................................................................... 6 1.8. ORGANIZACIÓN DEL DOCUMENTO .................................................................................................................. 6
CAPÍTULO 2. MARCO TEÓRICO ................................................................................................................... 8
2.1. CONCEPTO ................................................................................................................................................ 9 2.2. SITIO WEB ................................................................................................................................................ 9 2.3. ARQUITECTURA DE SITIOS WEB ..................................................................................................................... 9 2.4. ONTOLOGÍA ............................................................................................................................................ 10 2.5. DISEÑO WEB ........................................................................................................................................... 10 2.6. USABILIDAD ............................................................................................................................................ 11 2.7. MAPA CONCEPTUAL .................................................................................................................................. 11 2.8. XML ...................................................................................................................................................... 12 2.9. OWL ..................................................................................................................................................... 12 2.10. RELACIÓN ............................................................................................................................................... 12
2.10.1. Relación de hiperonimia-hiponimia ........................................................................................... 13 2.10.2. Relación Sintagmática ................................................................................................................ 13 2.10.3. Relación de meronimia .............................................................................................................. 14
2.10.3.1. Mereología ............................................................................................................................................ 14 2.10.3.2. Meronimias centrales ........................................................................................................................... 15 2.10.3.3. Meronimias no centrales ...................................................................................................................... 15 2.10.3.4. Propiedades secundarias de las relaciones parte-todo ......................................................................... 16
2.10.4. Relación topológica .................................................................................................................... 17 2.11. UML ..................................................................................................................................................... 17
2.11.1. Propiedades de las relaciones de agregación y composición para UML................................... 17 2.12. SISTEMAS DE NAVEGACIÓN DE SITIOS WEB .................................................................................................... 18
2.12.1. Conjunto primario de navegación ........................................................................................ 18 2.12.2. Conjunto secundario de navegación .................................................................................... 18 2.12.3. Conjunto terciario de navegación .............................................................................................. 18
CAPÍTULO 3. ESTADO DEL ARTE ................................................................................................................ 20
3.1. WEBTOC ............................................................................................................................................... 21 3.2. DREAMWEAVER ...................................................................................................................................... 22
3.2.1. Visualización del mapa del sitio ...................................................................................................... 22 3.3. SGMAPPER ............................................................................................................................................. 23
3.3.1. Organización jerárquica del sitio Web ............................................................................................ 23 3.3.2. Organización de red del sitio Web .................................................................................................. 23 3.3.3. Enlaces asociativo implícito ............................................................................................................ 23 3.3.4. Formato SGF ................................................................................................................................... 24 3.3.5. Implementación .............................................................................................................................. 24
3.4. URIGRAPH .............................................................................................................................................. 25 3.4.1. Capas del modelo Urigraph ............................................................................................................ 26
Página ii
3.4.2. Gramática XML ............................................................................................................................... 28 3.5. CMAPTOOLS ........................................................................................................................................... 29 3.6. OOWS (MÉTODO DE PRODUCCIÓN DE SOLUCIONES WEB ORIENTADOS A OBJETO) .............................................. 30
3.6.1. Especificación del problema ........................................................................................................... 30 3.7. TOUCH GRAPH ......................................................................................................................................... 32
3.7.1. TouchGraph propietario ................................................................................................................. 32 3.7.2. TouchGraph de código abierto ....................................................................................................... 32
3.7.2.1. LinkBrowser ........................................................................................................................................... 33 3.7.2.2. WikiBrowser .......................................................................................................................................... 34
3.8. PERSONALBRAIN ...................................................................................................................................... 34 3.8.1. El pensamiento activo .................................................................................................................... 34 3.8.2. Relaciones de pensamientos .......................................................................................................... 35
3.9. ONTOWEBBER ......................................................................................................................................... 36
CAPÍTULO 4. ANÁLISIS Y DISEÑO DE LA SOLUCIÓN ................................................................................... 38
4.1. DESCRIPCIÓN GENERAL DE LA SOLUCIÓN PROPUESTA ....................................................................................... 39 4.2. DESARROLLO DE UNA METODOLOGÍA PARA DEFINIR ESTRUCTURAS DE SITIOS WEB BASADA EN DISEÑO DE ONTOLOGÍAS 39
4.2.1. Estudio de los dominios de trabajo ................................................................................................ 39 4.2.1.1. Análisis de sitios Web de dominio educación (edu) .............................................................................. 39 4.2.1.2. Estructura de páginas ............................................................................................................................ 41
4.2.2. Construcción de una ontología del dominio de educación ............................................................ 44 4.2.2.1. Identificación del propósito de la ontología .......................................................................................... 44 4.2.2.2. Identificación de conceptos del dominio .............................................................................................. 44 4.2.2.3. Creación de la taxonomía de clases ...................................................................................................... 45 4.2.2.4. Atributos de las clases de la ontología .................................................................................................. 47 4.2.2.5. Definición de clases de la taxonomía .................................................................................................... 47 4.2.2.6. Establecimiento de relaciones de la ontología ...................................................................................... 50
4.3. EDITOR DE ESTRUCTURAS DE SITIOS WEB ...................................................................................................... 62 4.3.1. Análisis de requerimientos del usuario .......................................................................................... 62 4.3.2. Arquitectura general de la herramienta y descripción de las funciones ........................................ 62 4.3.3. Usuarios de la herramienta ............................................................................................................ 63 4.3.4. Limitaciones de la herramienta ...................................................................................................... 64
4.4. DISEÑO .................................................................................................................................................. 64 4.4.1. Diagramas de casos de uso ............................................................................................................. 64
CAPÍTULO 5. IMPLEMENTACIÓN .............................................................................................................. 69
5.1. CREACIÓN DE LA ONTOLOGÍA CON LA HERRAMIENTA PROTÉGÉ .......................................................................... 70 5.2. DESARROLLO DE LA APLICACIÓN .................................................................................................................. 71
5.2.1. Características generales de implementación ................................................................................ 71 5.2.2. Implementación de módulos .......................................................................................................... 72
5.2.2.1. Carga de la ontología............................................................................................................................. 72 5.2.2.2. Creación de grafos con la herramienta ................................................................................................. 73 5.2.2.3. Crear archivo XML a partir de un grafo ................................................................................................. 76 5.2.2.4. Generar grafo a partir de un archivo XML ............................................................................................. 78 5.2.2.5. Generar estructura del sitio Web .......................................................................................................... 79 5.2.2.6. Generar reporte de errores ................................................................................................................... 82 5.2.2.7. Validar la estructura de sitio Web ......................................................................................................... 83
CAPÍTULO 6. PRUEBAS ............................................................................................................................. 85
6.1. INTRODUCCIÓN ........................................................................................................................................ 86 6.2. HIPÓTESIS ............................................................................................................................................... 86 6.3. PRUEBA DE USABILIDAD ............................................................................................................................. 86
6.3.1. Descripción de las pruebas ............................................................................................................. 86 6.3.2. Problemas encontrados .................................................................................................................. 87
6.4. PLAN DE PRUEBAS..................................................................................................................................... 88
Página iii
6.4.1. Características a probar .................................................................................................................. 88 6.4.1.1. Pruebas de creación y edición de grafos ............................................................................................... 88 6.4.1.2. Pruebas de creación de estructuras de sitios Web ............................................................................... 89
6.4.2. Procedimiento de las pruebas ........................................................................................................ 89 6.4.2.1. EDWEB-101 Pruebas de creación y edición de grafos ........................................................................... 89 6.4.2.2. EDWEB-102 Pruebas de creación de estructuras de sitios Web ........................................................... 92
6.4.3. Resultados de las pruebas .............................................................................................................. 92
CAPÍTULO 7. CONCLUSIONES ..................................................................................................................102
7.1. CONCLUSIONES ...................................................................................................................................... 103 7.2. APORTACIONES ...................................................................................................................................... 103 7.3. TRABAJOS FUTUROS ................................................................................................................................ 103 7.4. PUBLICACIONES ...................................................................................................................................... 104
ANEXO A: .......................................................................................................................................................105
EJEMPLOS DE ETIQUETADO ...........................................................................................................................105
ANEXO B: .......................................................................................................................................................107
IMPLEMENTACIÓN .........................................................................................................................................107
REFERENCIAS .................................................................................................................................................116
Índice de figuras FIGURA 1.1. NÚMERO TOTAL DE SITIOS WEB. OCTUBRE 1995-JULIO 2008 ............................................................................. 4 FIGURA 3.1. EJEMPLO DE APLICACIÓN DE WEBTOC ........................................................................................................... 21 FIGURA 3.2. FUNCIONAMIENTO DEL CLIENTE .................................................................................................................... 25 FIGURA 3.3. EJEMPLO DE LA CAPA TOPOLÓGICA DE ............................................................................................................ 26 FIGURA 3.4. ESTRUCTURA DE LA URL EN URIGRAPH .......................................................................................................... 28 FIGURA 3.5. GRAMÁTICA XML DE URIGRAPH ................................................................................................................... 28 FIGURA 3.6. APROXIMACIÓN A LA METODOLOGÍA OOWS .................................................................................................. 30 FIGURA 3.7. EJEMPLO DE HINT ...................................................................................................................................... 33 FIGURA 3.8. TIPOS DE PENSAMIENTO .............................................................................................................................. 35 FIGURA 4.1. PÁGINA PRINCIPAL DEL CINVESTAV ............................................................................................................. 42 FIGURA 4.2. EJEMPLO DE ESTRUCTURA JERÁRQUICA ENTRE LA PÁGINA PRINCIPAL DEL CINVESTAV Y ELEMENTOS DEL GRUPO DE
NAVEGACIÓN PRIMARIO ...................................................................................................................................... 43 FIGURA 4.3. ENLACES DEL CONJUNTO SECUNDARIO DE NAVEGACIÓN ..................................................................................... 43 FIGURA 4.4. DIAGRAMA DE CLASES DE LA ONTOLOGÍA ........................................................................................................ 45 FIGURA 4.5. CONJUNTO DE RELACIONES .......................................................................................................................... 50 FIGURA 4.6. ARQUITECTURA GENERAL DEL EDITOR EDWEB ................................................................................................ 62 FIGURA 4.7. CASOS DE USO ........................................................................................................................................... 65 FIGURA 5.1. JERARQUÍA DE CLASES ................................................................................................................................. 70 FIGURA 5.2. CONJUNTO DE PROPIEDADES ........................................................................................................................ 71 FIGURA 5.3. CLASES PARA EXPLOTACIÓN DE LA ONTOLOGÍA ................................................................................................. 73 FIGURA 5.4. DIAGRAMA DE ACTIVIDADES PARA LA CREACIÓN DE GRAFOS ............................................................................... 74 FIGURA 5.5. CLASES PARA LA CREACIÓN DE GRAFOS ........................................................................................................... 75 FIGURA 5.6. DIAGRAMA DE ACTIVIDADES PARA LA CREACIÓN DE UN ARCHIVO XML ................................................................. 76 FIGURA 5.7. DIAGRAMA DE CLASES PARA LA CREACIÓN DE UN ARCHIVO XML ......................................................................... 77 FIGURA 5.8. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE UN GRAFO ................................................................................ 78 FIGURA 5.9. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE UN GRAFO ........................................................................ 79 FIGURA 5.10. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE ESTRUCTURAS DE SITIOS WEB ............................................. 80
Página iv
FIGURA 5.11. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE ESTRUCTURAS DE SITIOS WEB ..................................................... 81 FIGURA 5.12. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE REPORTE DE ERRORES ............................................................... 82 FIGURA 5.13. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE REPORTE DE ERRORES ....................................................... 83 FIGURA 5.14. DIAGRAMA DE ACTIVIDADES PARA LA VALIDACIÓN DE ESTRUCTURAS DE SITIOS WEB .............................................. 84 FIGURA 5.15. DIAGRAMA DE CLASES PARA LA VALIDACIÓN DE ESTRUCTURAS DE SITIOS WEB ...................................................... 84
Índice de tablas
TABLA 2.1. RELACIONES CENTRALES DE MERONIMIA CON FACTOR DE INTERFERENCIA "OPCIONALIDAD" ....................................... 15 TABLA 2.2. MERONIMIAS NO CENTRALES DE TIPO COLECTIVIDAD .......................................................................................... 16 TABLA 4.1. CONJUNTO DE SITIOS WEB ANALIZADOS........................................................................................................... 40 TABLA 4.2. DEFINICIÓN DE CLASES DE LA TAXONOMÍA ........................................................................................................ 46 TABLA 4.3. DEFINICIÓN DE LA CLASE DESCRIPCIÓN ABSTRACTA ............................................................................................. 47 TABLA 4.4. DEFINICIÓN DE LA CLASE DESCRIPCIÓN FÍSICA .................................................................................................... 48 TABLA 4.5. DEFINICIÓN DE LA CLASE ESTUDIANTE .............................................................................................................. 48 TABLA 4.6. DEFINICIÓN DE LA CLASE ORGANIZACIÓN FUNCIONAMIENTO ................................................................................ 48 TABLA 4.7. DEFINICIÓN DE LA CLASE PRODUCTO ............................................................................................................... 48 TABLA 4.8. DEFINICIÓN DE LA CLASE SERVICIO EXTERNO ..................................................................................................... 48 TABLA 4.9. DEFINICIÓN DE LA CLASE SERVICIO INTERNO ...................................................................................................... 49 TABLA 4.10. DEFINICIÓN DE LA CLASE SUCESO .................................................................................................................. 49 TABLA 4.11. DEFINICIÓN DE LA CLASE TRABAJADOR ........................................................................................................... 49 TABLA 4.12. DEFINICIÓN DE LA CLASE TRÁMITE ................................................................................................................ 49 TABLA 4.13. DEFINICIÓN DE LA CLASE UNIDAD ORGANIZACIONAL ......................................................................................... 50 TABLA 4.14. DOMINIO Y RANGO PARA LA RELACIÓN (A) MERONIMIA FACULTATIVA-FACULTATIVA ............................................. 51 TABLA 4.15. DOMINIO Y RANGO PARA LA RELACIÓN (B) MERONIMIA FACULTATIVA-FACULTATIVA ............................................. 52 TABLA 4.16. DOMINIO Y RANGO PARA LA RELACIÓN (C) MERONIMIA GRUPO-MIEMBRO: ........................................................ 52 TABLA 4.17. DOMINIO Y RANGO PARA LA RELACIÓN (D) MERONIMIA COLECCIÓN-MIEMBRO .................................................... 53 TABLA 4.18. DOMINIO Y RANGO PARA LA RELACIÓN (E) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 53 TABLA 4.19. DOMINIO Y RANGO PARA LA RELACIÓN (F) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 54 TABLA 4.20. DOMINIO Y RANGO PARA LA RELACIÓN (G) MERONIMIA CANÓNICA-CANÓNICA .................................................... 54 TABLA 4.21. DOMINIO Y RANGO PARA LA RELACIÓN (H) MERONIMIA CANÓNICA-CANÓNICA .................................................... 55 TABLA 4.22. DOMINIO Y RANGO DE LA RELACIÓN (I) MERONIMIA CANÓNICA-CANÓNICA ......................................................... 55 TABLA 4.23. DOMINIO Y RANGO PARA LA RELACIÓN (J) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 56 TABLA 4.24. DOMINIO Y RANGO PARA LA RELACIÓN (K) MERONIMIA CANÓNICA-FACULTATIVA ................................................. 56 TABLA 4.25. DOMINIO Y RANGO PARA LA RELACIÓN (L) MERONIMIA CANÓNICA-FACULTATIVA ................................................. 57 TABLA 4.26. DOMINIO Y RANGO PARA LA RELACIÓN (M) MERONIMIA CANÓNICA-FACULTATIVA ................................................ 57 TABLA 4.27. DOMINIO Y RANGO PARA LA RELACIÓN (N) MERONIMIA FACULTATIVA -CANÓNICA ................................................ 58 TABLA 4.28. DOMINIO Y RANGO PARA LA RELACIÓN TOPOLÓGICA ....................................................................................... 58 TABLA 4.29. DOMINIO Y RANGO PARA LA RELACIÓN PRODUCE ............................................................................................. 58 TABLA 4.30. DOMINIO Y RANGO PARA LA RELACIÓN REGISTRA ............................................................................................. 59 TABLA 4.31. CONJUNTO DE PROPIEDADES PARA RELACIONES MERONÍMICAS ........................................................................... 60 TABLA 4.32. PROPIEDADES DE CU-1 CREAR GRAFO DEL SITIO WEB ...................................................................................... 65 TABLA 4.33. PROPIEDADES DE CU-2 CREAR ARCHIVO XML A PARTIR DE UN GRAFO ................................................................. 66 TABLA 4.34. PROPIEDADES DE CU-3 GENERAR GRAFO A PARTIR DE UN ARCHIVO XML ............................................................. 66 TABLA 4.35. PROPIEDADES DE CU-4 GENERAR ESTRUCTURA DEL SITIO WEB .......................................................................... 66 TABLA 4.36. PROPIEDADES DE CU-5 CREAR REPORTE DE ERRORES ....................................................................................... 67 TABLA 4.37. PROPIEDADES DE CU-6 VALIDAR ESTRUCTURA DEL SITIO WEB ........................................................................... 67 TABLA 6.1. CASO DE PRUEBA EDWEB-101-001 CARGA DE LA ONTOLOGÍA .......................................................................... 93 TABLA 6.2. CASO DE PRUEBA EDWEB-101-002 CREAR UN GRAFO MANUAL ......................................................................... 94 TABLA 6.3. CASO DE PRUEBA EDWEB-101-003 GENERAR UN ARCHIVO XML ...................................................................... 94
Página v
TABLA 6.4. CASO DE PRUEBA EDWEB-101-004 GENERAR UN GRAFO AUTOMÁTICAMENTE ..................................................... 96 TABLA 6.5. CASO DE PRUEBA EDWEB-101-005 REPORTAR ENLACES INDEFINIDOS ................................................................. 97 TABLA 6.6. CASO DE PRUEBA EDWEB-101-006 VALIDAR EL GRAFO .................................................................................... 98 TABLA 6.7. CASO DE PRUEBA EDWEB-102-001 GENERAR ESTRUCTURA DEL SITIO WEB ......................................................... 99 TABLA 6.8. DESCRIPCIÓN DE GRAFOS DE LOS CASOS DE PRUEBA DE LA HERRAMIENTA EDWEB ................................................. 101
Capítulo 1. Introducción En el presente capítulo se exponen los antecedentes que dieron origen a la tesis; se describe el problema al cual se dio solución; se definen los objetivos de la presente investigación; sus alcances y limitaciones; y los beneficios que aporta. Finalmente, en el último apartado, se describe la organización del documento.
Capítulo 1. Introducción
Página 2
1.1. Antecedentes
La World Wide Web (WWW, Red Global Mundial) fue creada entre 1989 y 1990 por Tim Berners-Lee como la culminación del hipertexto, iniciando así una nueva era de difusión masiva de la información. A medida que la Web evolucionó se incrementaron sus funciones, apareciendo posteriormente los actuales navegadores y las interfaces gráficas así como diversos servicios en función de las necesidades del usuario. Éstas pueden ser de tipo informativo, transaccionales, de comunidad, entretenimiento, comerciales, de gobierno, de educación, personales, entre otras.
Con la evolución de internet surgió la necesidad de organizar la información y mejorar su explotación. Así nacieron conceptos tales como la Web semántica [W3C 2008] y se hizo popular el uso de ontologías, utilizadas desde hace varios años en diversas áreas de conocimiento, que permitieron comprender la información distribuida en la WWW
Las ontologías se fundamentan en la representación de la realidad por medio de conceptos, es decir, la abstracción de ciertos aspectos de entidades que existen en un dominio específico. Asimismo definen el modo en que dichas entidades se relacionan entre ellas. Tienen una posición central en la visión de la Web semántica, que se refiere a la integración y representación de datos, así como la manera en que se relacionan con los objetos de la vida real.
El término semántico fue introducido por el propio Berners-Lee, quien desde el inicio
de la WWW consideró la inclusión de información en las páginas de los sitios Web. Actualmente existen lenguajes y estándares para la representación de datos y la formalización de ontologías como: XML, RDF, RDF Schema y OWL, descritos en [OWL 2008]
La Web semántica brinda una mejora a internet porque proporciona información adicional que aporta significado y relaciones entre datos. Sin embargo, su propósito es facilitar la interoperabilidad entre los sistemas de información para reducir la intervención humana, es decir, que sea transparente para un usuario del sistema.
Esta tesis proporciona un enfoque dirigido al arquitecto de sitios Web, sin ignorar el impacto que tendrá en los usuarios finales del sitio. Su principal contribución consiste en una metodología basada en los conceptos de diseño de ontologías para agregar significado a las estructuras de sitios Web de un dominio específico dejando a un lado el contenido de las páginas.
La investigación realizada defiende la idea de que no sólo el contenido presenta
elementos que son utilizados para una mejor descripción del sitio Web. Sostiene además que la arquitectura posee conceptos que guardan ciertas relaciones entre ellos, en forma tal que ayudan a conceptualizar y definir un sitio Web para que su generación y mantenimiento sean más sencillos para el responsable del mismo.
Capítulo 1. Introducción
Página 3
1.2. Descripción del problema
En la actualidad existen millones de sitios de diferentes ámbitos, cada uno creado de acuerdo a patrones de diseño que consideran aspectos estéticos más que de organización del sitio. Desde el comienzo de la WWW, Berners-Lee intentó integrar aspectos semánticos en los sitios Web, sin conseguirlo. En consecuencia se desencadenó un problema relacionado con la creación de los mismos. Actualmente muchas páginas no poseen metadatos que describan la información contenida en los sitios, ni datos sobre su estructura. A raíz de la creación de la Web semántica se integró la parte semántica al contenido de las páginas. Sin embargo se ha dejado a un lado la arquitectura de los sitios Web.
Actualmente existen diferentes maneras de crear un sitio Web, utilizando plantillas
Cascading Style Sheets (CSS, Hoja de Estilo en Cascada) [W3C 2008c], mapas de sitios [DICIF 2008], mapas conceptuales [Novak 84], entre otras. Hay además herramientas que permiten la implementación de estas técnicas para la elaboración de sitios Web.
El uso de plantillas CSS se aplica al diseño Web, siendo de carácter estético y no de
composición. Los mapas de los sitios se elaboran siguiendo un patrón de grafo dirigido, en el que se establece la navegación del usuario entre páginas. Pero este grafo no incluye un etiquetado que establezca la relación directa entre los elementos que componen la estructura.
En el caso de los mapas conceptuales, el usuario establece manualmente las relaciones
entre los conceptos. Sin embargo, estas relaciones no presentan algún tipo de validación y mucho menos ayudan a definir su semántica.
Los métodos anteriores muestran la estructura de un sitio, proporcionan vistas del
acomodo de los elementos de las páginas y sugieren un modo de diseñar el sitio Web, pero no definen el significado de su estructura o, si lo hacen, no permiten su posterior utilización, a diferencia del enfoque presentado en este trabajo.
La importancia del problema señalado radica en la relevancia que adquiere la
estructura en el proceso de elaboración del sitio Web debido a que es la base que soporta la organización lógica de su información y su posterior mantenimiento. Una buena arquitectura del sitio Web asegura que el proceso de diseño sea más eficiente, lo cual no se logra si el diseñador no es capaz de expresar de manera clara cómo está conformada la estructura.
1.3. Objetivo
El objetivo de este trabajo de investigación es proporcionar elementos que permitan al arquitecto de sitios Web construir estructuras dotadas de significado que proporcionen mayor grado de comprensión y ayuden en la creación y mantenimiento del sitio. Para cumplir con este objetivo, se distinguen las siguientes actividades:
Capítulo 1. Introducción
Página 4
Estudiar los conceptos referentes al diseño de ontologías y la manera en que se aplican a la arquitectura de sitios Web.
Desarrollar una metodología para construir sitios Web basada en diseño de ontologías.
Elaborar un editor de sitios Web para validar la metodología de construcción de sitios Web.
1.4. Justificación
En el presente apartado se indican los puntos que justifican el trabajo de investigación realizado.
En base a una larga búsqueda no se encontraron trabajos que definan un modo de estructurar los sitios Web o que involucren una lógica de construcción al momento de realizar el modelado. La propuesta más cercana a este trabajo se refiere al uso de mapas conceptuales, en los que las relaciones y los conceptos sólo tienen significado para el arquitecto del sitio Web y no un significado preestablecido. Otros trabajos como [Adobe 2007], [Liechti 1998], [IHCM 2007], [TouchGraph 2007a], [Brain 2007] y [Jin 2001] sólo han desarrollado herramientas que visualizan el grafo del sitio Web.
El uso de sitios Web se ha diversificado y extendido con rapidez. De acuerdo a las estadísticas proporcionadas por el sitio [Netcraft 2008], en marzo del 2008 existían 162,662,052 sitios Web y para julio del 2008 la cantidad aumentó a 175,480,931 . Las cifras anteriores confirman la necesidad de incorporar semántica a la organización de los sitios Web.
Figura 1.1. Número total de sitios Web. Octubre 1995-Julio 2008
Fuente: http://news.netcraft.com/archives/2008/07/index.html
Capítulo 1. Introducción
Página 5
Estudios realizados por el Instituto para el Conocimiento Humano y Máquina (Institute for Human and Machine Cognition), revelan que el ser humano aprende y recuerda el conocimiento significativo a través de un conjunto de relaciones entre conceptos. Los mapas conceptuales aplican esta idea y ayudan a las personas a examinar diversos campos de conocimiento [Cañas 2001]. Utilizar elementos como mapas de conceptos en las estructuras de sitios Web implica que será más fácil para los diseñadores y usuarios utilizar estos sitios. Sin embargo, sería de mayor utilidad formalizar dichas relaciones y conceptos, tal como se establece en este trabajo.
El modelo relacional evolucionó hasta convertirse en el modelo entidad-relación que proporcionó semántica a su predecesor, pues el modelo relacional carecía de poder expresivo. Dicha evolución coloca al modelo relacional en un nivel inferior comparado con el modelo entidad-relación [Silberschartz 2006]. Integrar un componente semántico a la arquitectura de sitios Web, de la misma forma que el modelo entidad-relación añadió semántica al modelo relacional, conducirá a mejoras en la construcción en su estructura. De la misma manera, significaría una evolución con respecto a las herramientas utilizadas en la actualidad para producir grafos de sitios Web, debido a que estas herramientas trabajan de un modo similar al modelo relacional.
1.5. Alcances
A continuación se listan los puntos cubiertos en la tesis:
Estudiar las metodologías para diseño de ontologías. Analizar una muestra del dominio de sitios Web de educación, como caso de estudio. Estudiar las relaciones aplicables en la construcción de sitios Web, partiendo del
análisis de relaciones definidas en la lingüística y en UML. Definir formalmente las relaciones encontradas en el caso de estudio. Definir formalmente las clases de conceptos encontradas en el caso de estudio. Crear una herramienta para la edición de sitios Web con fines de prueba de la
metodología propuesta. El editor creado permite al usuario crear sitios Web y almacenar archivos descriptivos
de sus estructuras, así como generar páginas en blanco de dicha estructura.
1.6. Limitaciones
Se listan los puntos no cubiertos que delimitan el alcance de este trabajo.
La herramienta propuesta no ofrece la funcionalidad de crear un sitio Web de manera
automática, sino únicamente una estructura relacionada del sitio conformada de páginas en blanco que pueden ser editadas posteriormente por medio de herramientas de diseño.
Las relaciones definidas no contemplan elementos dinámicos ni de contenido del sitio Web (imagen, texto, etc.).
Capítulo 1. Introducción
Página 6
Se contemplan en los casos de uso la creación de un sitio Web nuevo, visualización de grafos creados a partir de archivos XML existentes y evaluación de un sitio Web editado con la herramienta.
En el caso de la creación de un sitio Web, no se etiqueta automáticamente el grafo, sino que el diseñador se encarga de tomar las relaciones convenientes para utilizarlas según se da el caso.
Las pruebas de usabilidad realizadas validan la hipótesis de las mejoras con respecto a la construcción y mantenimiento del sitio, no las posibles mejoras que encuentra un usuario al navegar por el sitio, es decir, estas pruebas se dirigen a quien crea el sitio y no a los usuarios finales del mismo.
No se contemplan elementos de diseño gráfico de la interfaz de usuario.
1.7. Beneficios
Los beneficios que derivados de esta tesis de investigación se listan a continuación:
La metodología establece conceptos y relaciones predefinidas como soporte en la
creación de sitios Web, elementos que hasta el momento no son ofrecidos por otras metodologías de construcción de sitios Web.
La metodología propuesta incluye la creación que una ontología que puede compartirse y extenderse, por lo que puede aplicarse a otros dominios de sitios Web.
Se valida la semántica de las relaciones predefinidas y su equivalente en una implementación.
El editor permite agregar una estructura lógica del sitio Web, partiendo de la metodología propuesta.
El diseñador del sitio se beneficia al poseer una herramienta que, al etiquetar el sitio, le permite más adelante, en caso de ser necesario, realizar cambios a la estructura de un modo más fácil.
Los sitios Web estructurados a partir de su semántica pueden brindar un mayor grado de comprensión para el diseñador del sitio.
1.8. Organización del documento
El documento de tesis se organiza en las secciones que se listan a continuación:
Capítulo 1: Introducción. Ubica al lector en el contexto del trabajo de investigación.
Hace referencia al panorama general del tema desarrollado.
Capítulo 2: Marco teórico. Contiene el conjunto central de conceptos que ayudan a la
comprensión de la investigación.
Capítulo 3: Estado del arte. Resume los trabajos relacionados, encontrados en la
literatura y que sirven como punto de referencia y comparación con el trabajo
propuesto.
Capítulo 4: Análisis y diseño de la solución.
Capítulo 5: Desarrollo de la investigación.
Capítulo 1. Introducción
Página 7
Capítulo 6: Implementación. Incluye elementos de codificación y las clases utilizadas
en cada caso de uso propuesto en el análisis.
Capítulo 7: Pruebas. Se desarrollan los casos de prueba previstos en el plan de
pruebas para el editor creado.
Capítulo 8: Conclusiones. Proporciona los resultados y observaciones finales de este
trabajo de investigación.
Capítulo 2. Marco teórico
Se expone a continuación, el conjunto de conceptos que sirven de guía al lector para tener una mejor comprensión del trabajo desarrollado.
Capítulo 2. Marco teórico
Página 9
2.1. Concepto
Un concepto, de acuerdo a la recopilación de Sager en diversas instituciones
estandarizadas [Sager 1990], puede definirse de acuerdo a las siguientes acepciones:
Los conceptos son constructos mentales, abstracciones que se pueden emplear para clasificar los distintos objetos del mundo exterior e interior (Recomendación Estándar Británica para la selección, formación y definición de términos técnicos).
Los objetos de todos los campos de conocimiento y actividades humanas, las cosas, sus propiedades, cualidades, fenómenos, etc., se representan mediante conceptos (Propuesta de revisión del Reino Unido para el documento de la ISO R/704).
Un concepto es un constructo mental para la clasificación de objetos individuales del mundo exterior e interior por medio de una abstracción más o menos arbitraria (Borrador de 1968 del estándar ISO 704).
Un concepto es una unidad de pensamiento, generada mediante la agrupación de objetos individuales relacionados entre sí por características comunes (Borrador de documento DIN, alemán).
Un concepto es un grupo coherente de juicios sobre un objeto cuyo núcleo se compone de aquellos juicios que reflejan las características inherentes del objeto (Propuesta de la Unión Soviética para la revisión del documento ISO 704).
Un concepto es una unidad de pensamiento.
2.2. Sitio Web
Un sitio Web es una serie o colección de páginas que definen la estructura del mismo y se identifican por una única dirección, Localizador Uniforme de Recurso (URL) [Cooley 2000]. Un sitio Web puede ser modelado como un grafo dirigido con nodos Web y arcos Web, donde los nodos corresponden a tipos de páginas (tales como HTML, PHP, ASP, CGI, JSP, etcétera.), y los arcos corresponden a los hipervínculos interconectando a las páginas Web [Lee 2006].
2.3. Arquitectura de sitios Web
De acuerdo con [Greenwich 2007], se define arquitectura de sitios Web como el arte y ciencia de crear buenos sitios Web, en donde se proporciona una amplia aproximación a la planeación y diseño de sitios Web. Se le llama arquitectura, porque, tal como lo hace arquitectura tradicional, implica aspectos de ingeniería, estéticos y funcionales, siendo algunos de sus requerimientos:
Contenido útil y bien organizado [Utilidad y comodidad]. Buenas técnicas de diseño [Eficiencia y firmeza]. Buen diseño visual [Belleza].
Capítulo 2. Marco teórico
Página 10
La arquitectura de sitios Web requiere especial atención al contenido Web, el plan de negocio de la empresa, la usabilidad, el diseño de interacción, la arquitectura de la información y el diseño Web.
Los puntos tradicionales de comodidad, firmeza y satisfacción que pueden guiar la
arquitectura de sitios Web se encuentran dentro de las etapas que inician con la planeación del contenido Web hasta el manejo del mismo, de la manera en que se encuentran en la arquitectura física y otras disciplinas de diseño.
2.4. Ontología
Especificación explícita y formal de una conceptualización compartida [Gruber 1993]. En esta definición, convertida ya en estándar, conceptualización se refiere a un modelo abstracto de algún fenómeno del mundo del que se identifican los conceptos que son relevantes; explícito hace referencia a la necesidad de especificar de forma consciente los distintos conceptos que conforman una ontología; formal indica que la especificación debe representarse por medio de un lenguaje de representación formalizado y compartida refleja que una ontología debe, en el mejor de los casos, dar cuenta de conocimiento aceptado (como mínimo, por el grupo de personas que deben usarla).
La ontología es una descripción de conceptos pertenecientes a un dominio, así como las relaciones existentes entre ellos. El estudio de las ontologías nace de la filosofía y proviene de las etimologías griegas “ontos” (el ser) y “logos” (estudio), que significaría el estudio del ser.
El término ontología en informática hace referencia al intento de formular un exhaustivo y riguroso esquema conceptual dentro de un dominio dado, con la finalidad de facilitar la comunicación y la compartición de la información entre diferentes sistemas.
2.5. Diseño Web
Búsqueda multidisciplinaria perteneciente al planeamiento y producción de sitios Web, incluyendo, pero no limitada a: desarrollo técnico, estructura de la información, diseño visual y entrega a través de la red [Powell 2002]. Hay cinco áreas que cubren la mayoría de las facetas del diseño Web:
Contenido: incluye la forma y organización del contenido del sitio. Puede tener un rango que va desde cómo el texto es escrito hasta cómo es organizado, presentado y estructurado, usando tecnologías tales como HTML.
Visual: se refiere a la disposición de la pantalla usada en un sitio. La disposición es creada usualmente con HTML, CSS o incluso Flash y puede incluir elementos gráficos de tipo decorativo o para navegación. El aspecto visual del sitio es el más obvio del diseño Web, pero no el único o el más importante.
Tecnológico: mientras el uso de varias tecnologías Web de capa, como HTML o CSS, caen dentro de esta categoría, tecnología en este contexto se refiere comúnmente a los
Capítulo 2. Marco teórico
Página 11
diversos elementos interactivos del sitio, particularmente aquellos construidos usando técnicas de programación. Tales elementos comprenden los lenguajes de guión del lado cliente, como JavaScript, y las aplicaciones del lado servidor, como los Java Servlets.
Envío: la velocidad y confiabilidad del envío de un sitio sobre internet o una red interna de una corporación está relacionada con el software y hardware del servidor usado y la arquitectura de red empleada.
Propósito: la razón de que el sitio exista, regularmente relacionado a aspectos económicos, es la parte más importante del diseño Web. Este elemento debe ser considerado en todas las decisiones que envuelvan a las otras áreas.
2.6. Usabilidad
La usabilidad, de acuerdo a [Nielsen 2003], es un atributo de calidad que mide lo fáciles de usar que son las interfaces de usuario. La palabra usabilidad se refiere además a los métodos para proveer facilidad de uso durante el proceso de diseño. La usabilidad se define por cinco componentes de calidad:
Aprendizaje: qué tan fácil es para los usuarios lograr las tareas básicas la primera vez que se enfrentan al diseño.
Eficiencia: una vez que los usuarios han aprendido el diseño, qué tan rápido desempeñan las tareas.
Recordable: cuando los usuarios usan el diseño después de un periodo de no usarlo, qué tan fácil se restablece su habilidad.
Errores: cuántos errores comete el usuario y qué tan fácil se recupera de ellos. Satisfacción: qué tan placentero resulta el diseño para el usuario.
2.7. Mapa conceptual
Los mapas conceptuales, desarrollados por Novak [Novak 1984] son usados para representar gráficamente conocimiento en todos los dominios, bajo la idea de que, en esta forma, el conocimiento puede ser fácilmente entendido por otros.
De acuerdo a los trabajos de investigación de Cañas [Cañas 2003], los mapas conceptuales están conformados de conceptos y relaciones entre ellos. Se define concepto como una regularidad percibida en un evento u objeto, o una serie de eventos u objetos, designado por una etiqueta. Los conceptos se encierran usualmente en círculos o cajas y las relaciones entre conceptos son indicadas por líneas de conexión que los enlazan. Las palabras en los enlaces especifican las relaciones entre los conceptos. La etiqueta para la mayoría de los conceptos es una sola palabra, aunque algunas veces se utilizan símbolos como + o %. La tripleta concepto-enlace-concepto conforma una proposición, es decir, una sentencia significativa sobre algún objeto o evento.
Capítulo 2. Marco teórico
Página 12
Otra característica de los mapas conceptuales es que los conceptos son representados en forma jerárquica con los conceptos más inclusivos en la parte superior del mapa y los conceptos más específicos debajo del mapa.
Además, algo importante y característico de los mapas conceptuales es la inclusión de enlaces cruzados. Esto crea una relación explícita entre conceptos en diferentes regiones o dominios dentro del mapa conceptual. Los enlaces cruzados muestran cómo un concepto, dentro de un dominio de conocimiento representado en el mapa, está relacionado con otro concepto en otro dominio mostrado en el mapa.
Los mapas conceptuales se aplican en diferentes áreas, una de ellas es la navegación
en internet.
2.8. XML
El metalenguaje Extensible Markup Language (XML, Lenguaje de Marcas Extensible) [W3C 2008b] es una simplificación y adaptación del Standard Generalized Markup Language (SGML, Lenguaje de Marcación Estandarizado) y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML) en un formato de texto simple y flexible. Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de los lenguajes que usan XML para su definición son: eXtensible Hypertext Markup Language (XHTML, Lenguaje Extensible de Marcado de Hipertexto), Scalable Vector Graphics (SVG, Gráfico Vectorial Escalable), Mathematical Markup Language (MathML, Lenguaje de Marcado Matemático).
XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.
2.9. OWL
Web Ontology Language (OWL) está diseñado para ser usado por aplicaciones que necesitan procesar el contenido de la información en lugar de solo presentar información al ser humano. OWL proporciona una mayor interpretabilidad del contenido Web que el soportado por XML, RDF y RDF Schema (RDF-S), proveyendo vocabulario adicional junto con semánticas formales. OWL tiene tres sublenguajes incrementalmente expresivos: OWL Lite, OWL DL y OWL Full [Mc GUINESS 2004].
2.10. Relación
Las relaciones en las ontologías se representan a través de tripletas, donde los elementos se toman de dos conjuntos C y R, cuyos elementos son llamados conceptos y relaciones.
Capítulo 2. Marco teórico
Página 13
De este modo existe una función de relación entre dos conceptos del conjunto C,
donde uno es el dominio y otro el rango, enlazados por medio de un elemento del conjunto R de relaciones.
2.10.1. Relación de hiperonimia-hiponimia
Una relación léxica de tipo genérico-específico [SIL 2008] es una asociación jerárquica entre unidades léxicas con un significado más amplio y general y otra unidad léxica con un significado más reducido y específico.
Dentro de esta relación, se envuelve la asociación entre:
Hipónimo: una unidad léxica (X) específica, con mayor complejidad semántica.
Hiperónimo: una unidad léxica (Y) general, con menor complejidad semántica.
X es un hipónimo de Y si:
La sentencia “X es necesariamente Y” es normal.
La sentencia “Y es necesariamente X” no es normal.
2.10.2. Relación Sintagmática
El sintagma es un término acuñado por [Saussure 1983], quien lo define así:
«Las palabras contraen entre sí, en virtud de su encadenamiento, relaciones fundadas en el carácter lineal de la lengua, que excluye la posibilidad de enunciar dos elementos a la vez. Los elementos se alinean uno tras otros en la cadena del habla. Estas combinaciones que se apoyan en extensión se pueden llamar sintagmas.
El sintagma se compone de dos o más unidades consecutivas (p. ej. re-leer; contra todos; la vida humana; Dios es bueno; si hace buen tiempo, saldremos; etc.) y colocado en un sintagma un término sólo tiene valor porque se opone al que le precede o al que le sigue o a ambos...La noción sintagma no sólo se aplica a las palabras, sino también a los grupos de palabras, a las unidades complejas de toda dimensión y de toda especie (palabras compuestas, derivadas, miembros de oración, oraciones enteras)...La oración es el tipo por excelencia de sintagma». Para los fines propuestos se utilizan los sintagmas predicativos, definidos por [Trubetzkoy 1939], que se encuentran compuestos por un sujeto y un predicado.
Capítulo 2. Marco teórico
Página 14
2.10.3. Relación de meronimia
La meronimia es una relación semántica no-simétrica entre los significados de dos palabras dentro del mismo campo semántico1. Se denomina merónimo a la palabra cuyo significado constituye una parte del significado total de otra palabra, denominada ésta holónimo. Por ejemplo, dedo es merónimo de mano y mano es merónimo de brazo; a su vez, brazo es holónimo de mano y mano es holónimo de dedo.
La relación de meronimia se define de la siguiente manera [DÍEZ 1999]:
Es la relación que existe entre partes y todo.
Es diferente de la hiponimia: un brazo no es un tipo de cuerpo, sino parte del
cuerpo.
Están sujetas a construcciones posesivas inalienables (frente a las alienables como
Juan tiene un libro o El libro de Juan). Esto quiere decir que las construcciones
posesivas no pueden transmitirse ni cederse.
2.10.3.1. Mereología
Mereología es la teoría de las relaciones de parte y todo y las relaciones de partes en un todo. Sus raíces comienzan en la filosofía, con el atomismo Presocrático y los escritos de Platón y Aristóteles.
En todas las teorías filosóficas de partes, la relación meronimia significa un orden parcial; es decir, una relación reflexiva, antisimétrica y transitiva, representada por los siguientes axiomas conocidos como Ground Mereology, pertenecientes a la Mereología Minimal:
x es parte de sí mismo
Si x es parte de y y y es parte de x, entonces x y y son iguales
Si x es parte de y y y es parte de z, entonces x es parte de z
Se define también dentro de esta teoría la parte propia con sus correspondientes axiomas:
x no es parte propia de sí mismo
1 Campo semántico: conjunto de palabras o elementos significantes con significados relacionados.
Capítulo 2. Marco teórico
Página 15
Si x es parte propia de y, entonces y no es parte propia de x
Si x es parte propia de y y y es parte propia de z, entonces x es parte propia de z
Las relaciones anteriores pueden denominarse “primitivas”, por lo que la Mereología Minimal evolucionó a lo que se conoce como Mereología Extensional y ésta, a su vez, a la Mereología Clásica, que incluye las operaciones de suma, producto, diferencia y complemento. 2.10.3.2. Meronimias centrales
Las meronimias centrales son un conjunto de relaciones encontradas en el trabajo de [Cruse 1986] que tienen su fundamento en relaciones de tipo léxico paradigmático y se aplican entre partes y todos de entidades físicas cohesionadas y tangibles, tomando en cuenta un factor de interferencia llamado “Opcionalidad” (Tabla 2.1).
Tabla 2.1. Relaciones centrales de meronimia con factor de interferencia "Opcionalidad"
Relación Descripción
Meronimia Canónica-Canónica2 Todo con parte obligatoria, parte obligatoria de un todo.
Meronimia Facultativa-Facultativa3 Todo con parte opcional, parte opcional de un todo.
Meronimia Facultativa-Canónica4 Todo con parte opcional, parte obligatoria de un todo.
Meronimia Canónica-Facultativa5 Todo con parte obligatoria, parte opcional de un todo.
Existen otras meronimias centrales con factores de interferencia tales como: congruencia,
espectro de sentidos y la holo-meronimia. 2.10.3.3. Meronimias no centrales
Las meronimias no centrales se encuentran, al igual que las centrales, en los trabajos de [Cruse 1986]. Las meronimias tomadas en cuenta en lo consecutivo son las colectividades, que se refieren a un tipo de entidades menos integrado estructuralmente que los objetos y sus partes son todas independientes –y a menudo diferenciadas- de un tipo más básico.
2 Meronimia C-C (en este documento)
3 Meronimia F-F (en este documento)
4 Meronimia F-C (en este documento)
5 Meronimia C-F (en este documento)
Capítulo 2. Marco teórico
Página 16
Tabla 2.2. Meronimias no centrales de tipo colectividad
Relación Descripción
Grupo-Miembro Asociaciones de humanos con un propósito o función común.
Clase-Miembro Agrupación con atributos comunes. Colección-Miembro Agrupación de objetos inanimados.
Otros tipos de meronimias no centrales son: lugares, ingredientes, partículas y
medidas.
2.10.3.4. Propiedades secundarias de las relaciones parte-todo A continuación se describen brevemente las propiedades de las meronimias contempladas en la Mereología Minimal, descritas en [Guizzardi 2005]. Estas propiedades son llamadas características secundarias y no están contempladas en las teorías de mereología clásica.
Parte exclusiva: x de tipo A es una parte (propia) exclusiva de otro individuo y de tipo
B si y sólo si y es el único B que tiene a x como parte.
Relación parte-todo exclusiva general (Gx): un universal A se relaciona con un B
universal por una relación de éste tipo, si cada instancia x de A tiene una parte
exclusiva de tipo B. Para toda x que pertenece a A existe una y que pertenece a B, tal
que x es parte de y.
Parte compartida: una parte compartida representa que las instancias de una clase no
pueden ser compartidas, pero el concepto representado por esa clase sí. Las partes
compartidas se consideran como roles explícitos. La etiqueta {conceptual} es
propuesta por [Saksena 1998], para representar el concepto compartido.
Dependencia existencial: denota existencia. Un individuo x es existencialmente
dependiente sobre otro individuo y, simbolizado como si y sólo si y debe
existir cuando x existe o formalmente:
Parte esencial: un individuo x es una parte esencial de y si y sólo si y es
existencialmente dependiente de x y x es necesariamente una parte de y. Se distingue
a la parte esencial con la etiqueta {essential=true}.
Parte obligatoria: un individuo x es una parte obligatoria de otro individuo y si y sólo
si y es genéricamente dependiente de un universo U que x instancia y y tiene
necesariamente como parte una instancia de U.
Individual extensional: un individuo y es llamado un individual extensional si y sólo
si para cada x tal que x es parte de y, x es una parte esencial de y.
Capítulo 2. Marco teórico
Página 17
Parte inseparable: un individuo x es una parte inseparable de otro individuo y si y
sólo si x es existencialmente dependiente sobre y y si x es necesariamente una parte de
y. Se distingue la parte inseparable con la etiqueta {inseparable=true}.
Todo obligatorio: un individuo y es un todo obligatorio para un individuo x si y sólo
si x es necesariamente parte de una instancia individual de U.
2.10.4. Relación topológica
La relación topológica [Díez 1999] es una relación léxica paradigmática que ocurre entre una unidad léxica que denota un contenedor, área o duración temporal y una unidad léxica que denota lo que está contenido en ellos o en un lugar alrededor. Es una relación que puede ser confundida con una meronimia. El dominio de la relación es un sustantivo (objeto de referencia) y el rango de la misma es otro sustantivo (objeto contenido o colocado en un lugar alrededor del objeto de referencia).
2.11. UML
Unified Modeling Language (UML, Lenguaje de Modelado Unificado) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas de software, así como para modelar negocios y otros sistemas que no son de software [UML 2005].
2.11.1. Propiedades de las relaciones de agregación y composición para UML
En [Manoli 2004] se plantea una diferenciación de las relaciones de agregación, composición y asociación a partir de ciertas características de UML, sin embargo, no es posible aplicarlas de manera directa como relaciones entre entidades de un sitio Web, debido a la naturaleza de las mismas. Es por ello que, a partir de la teoría sobre relaciones de este tipo se ha hecho una adaptación de las mismas.
Multiplicidad: la multiplicidad determina cuántos objetos participan en la relación, si una multiplicidad mínima es 0, indica que la relación es opcional, mientras que una multiplicidad mínima mayor o igual a 1 indica una relación obligatoria.
Propagación de borrado: indica qué acción debe ser ejecutada cuando un objeto es borrado (sobre sus enlaces o sus objetos asociados).
o {Restringida}: si el objeto tiene enlaces, no debe ser borrado. o {Cascada}: si el objeto tiene enlaces, los enlaces y los objetos asociados deben
ser borrados. o {Enlace}: si el objeto tiene enlaces, los enlaces deben ser borrados, no los
objetos asociados. Comportamiento temporal: especifica que una instancia puede ser conectada o
desconectada dinámicamente (creando o destruyendo un enlace) con una o más
Capítulo 2. Marco teórico
Página 18
instancias de una clase relacionada (por medio de relaciones de asociación/agregación) durante su existencia.
o Dinámico: indica que es posible crear o destruir un enlace durante el tiempo de vida completo del objeto.
o Estático: indica que el comportamiento anteriormente descrito solo es posible durante el proceso de creación.
2.12. Sistemas de navegación de sitios Web
Los sistemas de navegación son una pieza importante en la experiencia del usuario del sitio Web. De acuerdo a Rosenfeld [Rosenfeld 2006] existen tres conjuntos de navegación que se describen a continuación.
2.12.1. Conjunto primario de navegación
Este conjunto indica los accesos invariables del sitio, como una estructura de árbol, donde la página principal es el nodo raíz del que se desprenden los hijos, conformando un sistema de navegación jerárquico. Los enlaces de este tipo son estructurales, pues se encuentran definidos de manera fija en estructuras de acceso como menús y no embebidos en la información de las páginas, como se presenta en los sistemas de hipertexto6.
2.12.2. Conjunto secundario de navegación
Posee enlaces que normalmente son temporales, pues representan información relevante dentro del sitio en un momento específico, por lo que pueden desaparecer en cuanto pierden su carácter de importancia. Esta información proviene también de secciones internas del sitio, creando enlaces que rompen con el esquema de jerarquía orientándose a un estilo de Web pura.
Estos enlaces de tipo hipertextual se forman entre los elementos del árbol
proporcionando mayor flexibilidad a la navegación y añadiendo o retirando componentes.
2.12.3. Conjunto terciario de navegación
Contiene enlaces que aparecen en todo el sitio, por ejemplo, la función de búsqueda. A este esquema se le conoce también como sistema de navegación global.
6 Los sistemas de hipertexto se enfocan al contenido y sus relaciones.
Capítulo 2. Marco teórico
Página 19
La identificación de los esquemas de organización en el sitio permite identificar conceptos que se repiten en cada muestra e incluso detectar las partes de la estructura donde dichos conceptos se ubican.
Los conceptos encontrados en el dominio de sitios Web de educación se describen en
el diccionario del anexo A, aunque cabe aclarar que no son los únicos términos encontrados, sino aquellos que se tomaron por su continua aparición.
Capítulo 3. Estado del Arte
Este capítulo se enfoca en hacer una descripción de los trabajos y encontrados en la literatura que se asemejan en ciertas características a la propuesta descrita en capítulos posteriores. Estos trabajos sirven como un marco de referencia que ayuda a delimitar la investigación y a encontrar aspectos de mejora que se toman en cuenta al momento de llevarla a cabo.
Capítulo 3. Estado del arte
Página 21
3.1. WebTOC
WebTOC [Plaisant 1997] es una herramienta elaborada en Java que permite visualizar el contenido de un sitio Web. La visualización se lleva a cabo a través de una tabla jerárquica que organiza el contenido. Consta de dos partes:
1) Parser: analizador sintáctico que genera una tabla de contenidos (TOC7) para
representar el sitio.
2) Interfaz de usuario: un Applet de Java que muestra el TOC y proporciona interacción
dentro de un navegador convencional.
Figura 3.1. Ejemplo de aplicación de WebTOC
Fuente: ftp://ftp.cs.umd.edu/pub/hcil/Demos/WebTOC/Paper/WebTOC.html
Cada línea de texto del TOC representa un enlace a un documento, ya sea una página Web o un archivo multimedia. En la parte superior izquierda de la figura 3.1 se observa un panel de control con una barra de colores que representan cuatro tipos de elementos del sitio: texto, imagen, audio y otros. Debajo de la barra de colores hay una escala para indicar el tamaño de los archivos que inicia con 1kb (1000 bytes).
En la parte inferior izquierda de la figura 3.1 se despliega el TOC del sitio. Una barra a
la derecha de cada etiqueta de la jerarquía indica los tipos de archivos (tomando en cuenta la barra de colores) y su tamaño.
7 Tabla de Contenido, por sus siglas en inglés.
Capítulo 3. Estado del arte
Página 22
Para generar automáticamente la tabla de contenidos primero se limita el análisis a los enlaces locales del sitio Web8. Existe también una opción para mostrar enlaces externos en el WebToc, sin indicar el tamaño o tipo de documentos. Posteriormente, el analizador sintáctico genera un archivo con formato similar al HTML, que contiene información del servidor e indica el inicio y fin de un grupo de enlaces e información sobre cada documento o enlace. El archivo creado tiene una extensión “.hdir”.
3.2. DreamWeaver
Dreamweaver versión 8.0 [Adobe 2007] es un editor HTML profesional para diseñar, codificar y desarrollar sitios, páginas y aplicaciones Web. Trabaja en un entorno de codificación HTML manual y en un ambiente visual. Esta herramienta ofrece entornos de codificación de otras funciones. Incluye elementos para la edición de código y material de referencia sobre HTML, CSS, JavaScript, ColdFusion Markup Languaje (CFML), Microsoft Active Server Pages (ASP) y JavaServer Pages (JSP). Además, Dreamweaver permite visualizar la carpeta local de un sitio en forma de mapa visual de íconos vinculados, denominado mapa del sitio. Los mapas del sitio sirven para añadir nuevos archivos a un sitio de Dreamweaver y para agregar, modificar o eliminar vínculos.
3.2.1. Visualización del mapa del sitio
Para ver el mapa del sitio, se define primero una página principal, que puede ser cualquier página del sitio Web. No es necesario que sea la página inicial, pues ésta es sólo el punto de partida del grafo. La herramienta proporciona un menú que muestra el sitio, el servidor o la unidad actual. Luego se selecciona un archivo para que sea convertido en la página principal. Dreamweaver señala cada elemento del mapa del sitio con colores:
Texto en rojo: indica un vínculo roto.
Texto en azul y marcado con un icono de globo terráqueo: indica un archivo de otro
sitio o un vínculo especial (por ejemplo, un correo electrónico o script).
Marca de verificación verde: indica un archivo protegido por el autor.
Marca de verificación roja: indica un archivo protegido por otro usuario.
Ícono de candado: indica un archivo de sólo lectura (Windows) o bloqueado
(Macintosh).
8 WebTOC sigue los enlaces o nombres de directorios para construir un árbol jerárquico del sitio.
Capítulo 3. Estado del arte
Página 23
Trabajar con un mapa de sitio permite seleccionar páginas, abrirlas para editarlas, añadir nuevas páginas al sitio, crear vínculos entre archivos y cambiar títulos de páginas. Incluso pueden observarse detalles de una sección específica de un sitio al convertir una rama en el centro del mapa del sitio.
3.3. SGMapper
SGMapper [Liechti 1998] es una herramienta que utiliza metadatos SGF9 para generar mapas de sitio interactivos. Los grafos estructurados proporcionan navegación escalable y la posibilidad de editar grafos grandes. Brindan además una distinción entre enlaces jerárquicos y asociativos. Estos dos tipos de enlaces se denominan explícitos. También se crean enlaces asociativos implícitos para mostrar asociaciones entre subjerarquías.
3.3.1. Organización jerárquica del sitio Web
Un sitio Web puede organizarse como una jerarquía en base a metadatos SGF. Esta organización refleja relaciones de agregación y proporciona facilidad de exploración. Posteriormente los datos se envían a un servidor y se muestran en SGMapper.
El usuario selecciona un nodo para expandir la jerarquía. Si un usuario presiona dos veces un nodo, la URL correspondiente se descarga y se muestra en el navegador.
3.3.2. Organización de red del sitio Web
La relación asociativa define la estructura de red de un sitio Web. Explorar una estructura de red tendría los mismos resultados que explorar una jerarquía.
3.3.3. Enlaces asociativo implícito
Sean A y B dos subjerarquías con, por lo menos, un enlace asociativo explícito entre dos elementos a y b, donde a pertenece a A y b pertenece a B, se dice que existe una relación asociativa implícita entre A y B.
9 Formato de Grafo Estructurado, por sus siglas en inglés.
Capítulo 3. Estado del arte
Página 24
3.3.4. Formato SGF
Para describir el sitio Web se utiliza el formato SGF, que ayuda a codificar la información.
Existe una especificación SGF, en la forma de una DTD10 XML usada para codificar metadatos de nodos y enlaces. La DTD contiene restricciones para una clase de documento. Algunas de las restricciones válidas del formato SGF se muestran a continuación, de manera breve:
El sitio Web se captura como un grafo estructurado. La raíz de un documento SGF debe ser un elemento del tipo grafo estructurado. Un elemento del tipo grafo estructurado puede tener un número arbitrario de
subelementos, seguidos por subelementos de tipo nodos, jerarquías y redes. Los elementos nodo pueden tener un número arbitrario de elementos nodo. Los elementos de tipo jerarquía pueden tener un número arbitrario de enlaces. Los elementos de tipo red pueden tener un número arbitrario de enlaces
Un elemento nodo debe tener un identificador único. Un elemento nodo puede tener un atributo de etiqueta. Un elemento nodo puede tener un número arbitrario de subelementos. Un enlace debe tener un atributo de fuente, para el cual debe existir un identificador
único. Un enlace debe tener un atributo de destino, para el cual debe existir un identificador
único. Un enlace puede tener un atributo de etiqueta. Un enlace puede tener un número arbitrario de subelementos. Un subelemento debe tener dos atributos: nombre y valor.
El uso de subelementos hace extensible al SGF, permitiéndole la adición de
información específica de la aplicación.
3.3.5. Implementación
La herramienta cliente necesita tres elementos: un navegador Web estándar para acceder a la información en la Web, un visor interactivo para realizar el análisis de los documentos SGF y visualizar la estructura del sitio y un programa espía que pueda realizar la comunicación entre los dos anteriores. La comunicación se lleva a cabo por medio de mensajes.
El comportamiento del sistema se describe en la figura 3.2.
10
Descripción de Tipo de Documento, por sus siglas en inglés.
Capítulo 3. Estado del arte
Página 25
Figura 3.2. Funcionamiento del cliente
1) El espía manda un mensaje de eco para recibir como respuesta otro mensaje cuando
una URL sea descargada por el navegador. 2) El espía manda un mensaje para indicar que soporta archivos SGF y así el recurso sea
descargado. 3) El recurso es traído desde el navegador. 4) El navegador avisa al espía que se ha descargado una URL y manda el tipo MIME
para ser verificado en el espía. 5) Se verifica que sea un tipo SGF. 6) El documento SGF es traído por el navegador y éste lo almacena en disco, enviando
una solicitud al espía para que lo abra. 7) Cuando el navegador ha enviado el documento al espía, éste manda los metadatos al
visor para mostrarlos. 8) Cuando un usuario presiona dos veces sobre un nodo del visor, este último alerta al
espía. 9) El espía le solicita al navegador descargar la URL correspondiente. 10) El recurso finalmente es traído y mostrado en el navegador.
Del lado del servidor sólo debe cuidarse que el documento SGF exista en el servidor y
sea accesible al menos por un hipervínculo y que cuando se mande este documento al cliente, el servidor especifique explícitamente que es un documento SGF.
3.4. UriGraph
UriGraph es un modelo de estructuración de sitios Web que especifica la identidad, identificador, posición y composición de cada recurso que constituye el sitio Web [Simic 2002].
Identidad: intención del concepto representado. Conjunto de los atributos que definen al concepto
Identificador: representado por la URI. Debe comunicar la información de la identidad del recurso.
Capítulo 3. Estado del arte
Página 26
Composición: cada recurso Web se compone de varias partes o componentes de recurso.
Posición: define las relaciones de un recurso con otros componentes de ese sitio.
El modelo Urigraph [Simic 2003] utiliza análisis de URI a través de un grafo dirigido. Este modelo se divide en tres capas, descritas a continuación.
3.4.1. Capas del modelo Urigraph
1) Capa topológica
Figura 3.3. Ejemplo de la capa topológica de
UriGraph
Fuente: [Simic 02]
Define un grafo G=(V,E) donde:
V = {conjunto de n nodos | v1 hasta vn Є V} E= {conjunto de aristas ≠ V} Existe una relación binaria entre V y E. Hay dos tipos de nodos: P= {conjunto de nodos sitio} T= {conjunto de nodos transición} ∃(r) | r= nodo raíz análogo a la página principal del grafo dirigido. ∀(v) ∃( Dv) | (v Є V)^es(Dv , conjunto de nodos destino)
Para cada nodo v existe un conjunto de nodos destino Dv que consiste en todos los
nodos conectados al nodo v a través de sus aristas salientes.
Capítulo 3. Estado del arte
Página 27
Los nodos sitio son representados por círculos. Los nodos transición se representan como rectángulos anchos y las aristas como flechas. El nodo raíz se marca con el símbolo de una casa (figura 3).
Los nodos sitio simbolizan clases de recursos que contienen uno o varios recursos
similares que difieren en contenido, pero no en el modo en que son representados en el sitio. El nodo raíz es la página principal del sitio y los nodos transición marcan el análisis de piezas de información.
Los términos básicos de la topología son:
Camino: secuencia de nodos donde dos nodos consecutivos se conectan con una arista en la misma dirección.
Pasaje: camino que comienza en el nodo raíz y termina con un nodo sitio. Circuito: camino que comienza y termina en el mismo nodo.
Los casos de conexiones imposibles se muestran a continuación:
Las conexiones no son reflexivas: un nodo no se conecta consigo mismo. No hay conexión directa de dos nodos sitio. Una transición sólo puede tener una arista de salida a un nodo sitio, como máximo.
2) Capa de análisis de solicitud
Capa intermedia que define las reglas para analizar el identificador del recurso. El identificador del recurso distingue dos partes de la URI, la ruta y la solicitud, por lo que la capa intermedia aloja dos secuencias, una secuencia de segmentos de ruta y una secuencia de segmentos de solicitud (figura 3.4). El análisis del identificador inicia en el nodo raíz con un contenedor lleno de todos los segmentos de la solicitud HTTP y sigue las aristas a través de los nodos. El análisis termina regularmente en algún nodo sitio con un contenedor vacío, así se construye un pasaje en el grafo. Si el análisis termina en un nodo transición se considera la solicitud como incompleta y el análisis es insatisfactorio.
Capítulo 3. Estado del arte
Página 28
Figura 3.4. Estructura de la URL en Urigraph
3) Capa de síntesis de respuesta
La capa más alta de la arquitectura, define cómo la información es extraída de la solicitud e integrada en la respuesta. La respuesta contiene la identidad y composición del recurso identificado por la solicitud. La información de respuesta no es gráfica.
3.4.2. Gramática XML
La gramática XML se usa para descripciones y consiste en una estructura de elementos que encierra nodos sitio, transiciones de ruta y transiciones de solicitud. Estos elementos ayudan a representar varios tipos de nodos. Cada nodo posee un identificador usado para conectar un subelemento connectTo. Un ejemplo de la gramática para la figura 3.4 se muestra a continuación.
Figura 3.5. Gramática XML de Urigraph
Capítulo 3. Estado del arte
Página 29
3.5. CmapTools
El software CmapTools [IHCM 2007] se desarrolló en el IHMC11 y proporciona el uso de mapas conceptuales, particularmente en la WWW. Permite crear mapas de conceptos para organizar contenidos y colaborar con la creación de mapas a distancia. Utiliza una arquitectura cliente/servidor. Los usuarios comparten sus mapas en un servidor.
CmapTools permite disponer grandes cantidades de documentación (imágenes, texto, videos y páginas Web) de tal forma que el acceso sea fácil, a través de la navegación de mapas conceptuales sobre un tema determinado.
Los mapas conceptuales son una opción ante el problema de los usuarios para encontrar un modelo de organización de páginas o no conocer el contenido de las páginas a las que tendrán acceso con ciertos enlaces. Esto se debe a que, al seleccionar las ligas o enlaces, el usuario frecuentemente no tiene idea de cuál será el contenido de la página destino.
CmapTools utiliza los conceptos de modelos conceptuales, tales como nodos que se enlazan con relaciones. Estos enlaces están etiquetados. En cada nodo o concepto del mapa, el usuario dispone de un menú de íconos. Éstos corresponden a diversos medios (texto, imágenes, video, otros mapas conceptuales, etc.) relacionados al tema del nodo (concepto) seleccionado. Al seleccionar un icono, el sistema despliega información de otros recursos referentes al concepto.
Los íconos aparecen en diversas combinaciones dependiendo de la información disponible sobre el concepto dado. Todas las ligas tienen semántica definida por el diseñador del sitio, ya sea explícita en el mapa o por contexto al navegar entre mapas u otros medios. El usuario sabe entonces hacia dónde va cuando sigue una liga, en contraste con otras herramientas de navegación, especialmente en la WWW.
Para construir los mapas se usa un editor. El usuario relaciona los medios (video, imágenes, sonido, mapas, entre otros) y sus iconos con los nodos (conceptos). Aprovechando la extensión y omnipresencia de Internet, se construyen sistemas de multimedia accesibles desde cualquier lugar del mundo. El programa está escrito en Java y se ejecuta en cualquier plataforma computacional (Windows, Macintosh, UNIX, etc.)
Existen herramientas similares a CmapTools, tales como:
View Your Mind12
DeepaMehta13
11 El Instituto para la Cognición Humano y Máquina es una institución de investigación sin fines de lucro del
Sistema de Universidades de Florida. 12
Página oficial del software View Your Mind: http://www.insilmaril.de/vym/
Capítulo 3. Estado del arte
Página 30
Estas herramientas no se reportan debido a que sus características no varían en comparación con CmapTools.
3.6. OOWS (Método de Producción de Soluciones Web Orientado a Objeto)
El Método OOWS [Fons 2002] es una extensión del Método OO para la generación automática de código usando modelos conceptuales, que se basa a su vez en OASIS14. OOWS permite capturar y representar la semántica de navegación y de presentación de la información por medio de primitivas de abstracción de alto nivel. Posteriormente conforma un repositorio de requisitos básicos de construcción, procesados con la finalidad de generar interfaces de usuario.
Figura 3.6. Aproximación a la metodología OOWS
El modelado del sistema con OOWS abarca dos pasos: la especificación del problema
y el desarrollo de la solución.
3.6.1. Especificación del problema
Comprende la captura del comportamiento que satisface los requisitos de los usuarios identificados.
13
Página oficial del software DeepaMehta: http://www.deepamehta.de/ 14
Por sus siglas en inglés, Especificación Abierta y Activa de Sistemas de Información. Es un enfoque formal
para la especificación de modelos conceptuales siguiendo el paradigma orientado a objetos.
Capítulo 3. Estado del arte
Página 31
En la especificación del problema se desarrolla la fase del Modelado Conceptual que divide su operación en los siguientes modelos [Fons 2002]:
A) Modelo semántico: se define la estructura del sistema (clases, operaciones y atributos)
y las relaciones estructurales entre clases por medio de un Diagrama de Clase. B) Modelo dinámico: captura las interacciones entre objetos.
C) Modelo funcional: toma la semántica de cambios de estado.
La parte complementaria al Método OO integra dos modelos:
D) Modelo de Navegación: proporciona a los usuarios acceso a la información y la
funcionalidad para llevar a cabo sus tareas dentro del sistema y las secuencias de
caminos que deben seguir para conseguirlo.
Se compone de un conjunto de mapas de navegación cuya función es representar la visión global del sistema para cada tipo de usuario, definiendo su navegación permitida. Éste se representa usando un grafo dirigido donde los nodos son los contextos de navegación y los arcos son enlaces de navegación.
Un contexto de navegación es una unidad de interacción abstracta que representa una vista sobre un conjunto de datos y servicios accesible para un usuario en un determinado momento. Está compuesto por un conjunto de clases de navegación haciendo referencia a las clases identificadas en el modelo de objetos, con las que se define la visibilidad ofrecida al agente en ese nodo.
E) Modelo de presentación: cuando el modelo de navegación captura la semántica de
navegación del sistema, se asocian características de presentación al mismo. El modelo
de presentación complementa la información capturada en el modelo de navegación
para crear las interfaces con información de presentación.
Tras el modelado, se genera el código basándose en la recopilación de requisitos, por medio del compilador de modelos conceptuales (model compiler) que, en función de patrones arquitectónicos y dependiendo de la plataforma destino, construye el sistema de software que recoge los requisitos de aplicación modelada.
El Método OO maneja diferentes tipos de relaciones que son correspondientes a
algunas relaciones de UML [Insfrán 1998].
1) Agregación, también conocida como “parte de”: relación jerárquica en la que el concepto de nodo padre es más amplio que el de los nodos hijo. La relación de agregación es no reflexiva, no simétrica y transitiva.
2) Herencia, también conocida como “es un”. A) Especialización: trata la herencia descendiente o derivación de clases hijas a
partir de una clase padre.
Capítulo 3. Estado del arte
Página 32
B) Generalización: es la inversa de la especialización. Tratar la herencia ascendente o generación de clases (padre) a partir de propiedades comunes de clases definidas (hijas) con anterioridad.
3) Agentes: relación entre objetos cliente y servidor.
3.7. Touch Graph
TouchGraph [TouchGraph 2007a] es una herramienta realizada en Java para visualización de redes de información relacionadas entre sí, mostrando grafos interactivos. Por medio de una imagen visual, un usuario puede navegar a través de redes de gran tamaño. La solución de visualización propuesta permite mostrar relaciones entre personas, organizaciones e ideas.
El proyecto TouchGraph se divide en dos modalidades, propietario y de código abierto, presentadas a continuación.
3.7.1. TouchGraph propietario
Integra visualización gráfica de componentes tradicionales de tablas y árboles para descubrir información, proveyendo soluciones ad-hoc a las necesidades de empresas y compañías. La plataforma permite el acceso a cualquier fuente de información conectado o no conectado a internet, así como la generación de reportes en hojas de cálculo o imágenes en archivos PDF.
El sitio Web muestra el funcionamiento de TouchGraph en un navegador de demostración para el sitio Amazon, un navegador para la visualización de redes sociales aprovechando la plataforma de Facebook15 y una aplicación para explorar conexiones entre sitios relacionados usando datos obtenidos de Google .
3.7.2. TouchGraph de código abierto
La idea de TouchGraph fue concebida por Alex Shapiro, como una combinación de elementos de herramientas de visualización propietarias como inXigth y TheBrain, usando el lenguaje Java bajo el sistema CVS16.
A continuación se analizarán dos de las aplicaciones relevantes contenidas en el repositorio.
15
Facebook es un sitio Web de redes sociales (estructuras sociales representadas por grafos donde los nodos son
individuos y las aristas las relaciones entre ellos). Página oficial de Facebook: http://www.facebook.com/ 16
Sistema de control de versiones, por sus siglas en inglés: mantiene el registro de los trabajos y cambios en los
ficheros que forman un proyecto y permite la colaboración entre desarrolladores.
Capítulo 3. Estado del arte
Página 33
3.7.2.1. LinkBrowser
Grafica desde archivos XML (TG-XML) Genera grafos y los almacena en archivos TG-XML.
A) Inclusión de Hints (información adicional) de los nodos
Figura 3.7. Ejemplo de Hint
Los nodos pueden contener información adicional como archivos HTML, hiperenlaces
o imágenes. La información de cada nodo aparece en marcos internos. La información adicional de cada nodo puede desplegar archivos HTML externos
mediante el uso de marcos.
B) Uso de URL´s
Los nodos pueden tener URL´s asociadas, que actúan al seleccionar un nodo y presionarlo.
Las URL´s pueden marcarse como locales o remotas. Una URL local no necesita usar el prefijo “http://” y las páginas asociadas pueden cargarse en un marco interno. Las URL´s remotas aparecen por separado en una ventana de navegador distinta.
Las URL´s pueden marcarse como archivos XML. Cuando se presiona un nodo, se lee un archivo TG-XML y se carga el grafo que éste especifica.
Se proporciona un botón de retorno para volver a un archivo TG-XML cargado previamente.
Capítulo 3. Estado del arte
Página 34
3.7.2.2. WikiBrowser
TouchGraph WikiBrowser [TouchGraph 2007b] es una demostración de cómo TouchGraph puede usarse para visualizar una wiki. Actualmente la versión de prueba presenta las bases de datos de enlaces Meatball Wiki y EmacsWiki, pero ninguna otra base de datos codificada en un formato similar puede mostrarse.
Por ahora, la herramienta es una versión de prueba debido a que la base de datos de enlaces no se actualiza dinámicamente mientras se navega o carga desde una URL antes de activar la visualización. Para solucionarlo se plantea adquirir la estructura de enlaces por medio de una API basada en XML.
Las bases de datos de enlaces proporcionan una lista de todos los enlaces de páginas de una wiki local. El primer enlace en cada línea es la página que está siendo buscada y los siguientes enlaces son aquellos que fueron encontrados en dicha página. WikiBrowser es capaz de crear un grafo a partir de las bases de datos de hiperenlaces.
La aplicación consta de un navegador HTML convencional en la parte izquierda y un grafo en el lado derecho de la pantalla. Las etiquetas del nodo corresponden a las páginas de hipertexto, conectadas por enlaces que representan los hiperenlaces entre las páginas. Los nodos de color café muestran hiperenlaces de páginas internas de la wiki y los púrpura simbolizan a las páginas externas.
3.8. PersonalBrain
PersonalBrain [Brain 2007] es un software desarrollado por medio de la tecnología de modelado de información llamada “The Brain”, que funciona bajo la idea de que la información se almacena del mismo modo en que el cerebro lo hace, de manera intuitiva, con asociaciones entre los pensamientos que están contenidos ilimitadamente en el cerebro.
PersonalBrain usa como bloque básico de construcción un formato de dato llamado pensamiento (thought). Los pensamientos pueden ser un tipo de información cualquiera, como conceptos, proyectos, personas, materias, documentos, páginas Web, etc.
La herramienta permite crear enlaces y asociaciones entre los pensamientos, formando
una interfaz visual que refleja estas asociaciones en un grafo. Un cerebro no es una estructura jerárquica, ningún pensamiento es más importante que otro, por ello el usuario puede representar el modo en que se relacionan y lo que contienen.
3.8.1. El pensamiento activo
Al centro de PersonalBrain hay un pensamiento activo que representa el concepto central sobre el que se dibuja una serie de pensamientos relacionados en diferentes zonas.
Capítulo 3. Estado del arte
Página 35
Las zonas son áreas que manejan relaciones específicas del pensamiento central. Hay cuatro zonas: la zona de padres, la zona de hijos, la zona de saltos y la zona de hermanos.
3.8.2. Relaciones de pensamientos
La idea de PersonalBrain es crear y mostrar relaciones entre tipos de información. Las relaciones se construyen creando y ordenando pensamientos hijos, padres y saltos. Los nombres de las relaciones no tienen relación con el tipo de información que pueden contener, solamente describen su asociación con el pensamiento activo y las relaciones entre ellos.
Hay cuatro tipos de relaciones entre pensamientos: padre, hijo, salto y hermano [Brain 2004].
Figura 3.8. Tipos de pensamiento
Padre: un pensamiento padre tiene al menos un pensamiento debajo de él, es desplegado en la zona de padres, directamente sobre el pensamiento activo. Un pensamiento puede tener múltiples padres (un máximo de 32).
Hijo: es una subcategoría de un pensamiento activo. Varios pensamientos pueden compartir un padre. El máximo número de pensamientos hijos que puede tener un padre es de 128.
Hermano: un pensamiento hermano comparte el mismo padre que un pensamiento activo. Los hermanos son parte de un grupo cuya fuente de temas es el pensamiento padre.
Salto: un pensamiento de salto se relaciona con el pensamiento activo, pero no es una subcategoría. Los saltos se usan para crear relaciones entre grupos de pensamientos que están desplegados en la zona de salto. El máximo número de pensamientos de salto es de 32.
Los nodos se organizan en zonas: la zona de padres está sobre el pensamiento activo,
la zona de hijos debajo de él, la zona de saltos a la izquierda y la zona de hermanos a la derecha.
Capítulo 3. Estado del arte
Página 36
Los pensamientos están relacionados de manera directa o indirecta en virtud de que pertenecen al mismo cerebro, donde el cerebro es el conjunto que contiene a los pensamientos y sus enlaces. No hay reglas que gobiernen la creación de relaciones entre pensamientos.
3.9. OntoWebber
Esta herramienta [Jin 2001] adopta el modelo-dirigido de aproximación basado en ontologías para el manejo de sitios Web declarativos e integración de datos. Al mismo tiempo ofrece soporte a través del ciclo de vida del sitio Web, que incluye diseño, generación, personalización y mantenimiento. La idea fundamental detrás de OntoWebber es el uso de ontologías como la base de construcción de diferentes modelos necesarios para la creación de un sitio Web.
Su arquitectura se descompone en cuatro capas:
Capa de integración: resuelve las diferencias sintácticas entre datos heterogéneos
distribuidos en varias fuentes.
Capa de articulación: resuelve las diferencias semánticas entre las fuentes de datos.
Capa de composición: las ontologías para un modelo de un sitio son un conjunto de
esquemas predefinidos, disponibles en un repositorio central. Una vista del sitio
particular consiste en un conjunto de páginas Web que pueden ser creadas a partir de
datos señalados. La especificación de una vista del sitio es un conjunto de modelos de
sitios encargados de describir distintos aspectos de una vista del sitio basada en las
ontologías de modelado del sitio. Esta vista se exporta al motor de solicitudes.
Capa de generación: un sitio navegable puede generarse instanciando la vista del sitio
correspondiente, con datos en el repositorio. Esto se lleva a cabo con el motor de
solicitud.
Capítulo 3. Estado del arte
Página 37
Tabla 3.1. Comparación de herramientas del estado del arte
Característica
Herramienta
Representar la estructura del
sitio Web
Permitir creación o edición de
representaciones gráficas del sitio
Relacionar semánticamente el grafo del sitio
Web
Establecer reglas en el
formato para los elementos
de la representación
gráfica
Proporcionar restricciones de construcción del
sitio Web
Generar archivo XML u otro formato de estructura
validada del grafo
Generar las páginas de la estructura del sitio Web de
forma automática
Disponibilidad de la herramienta
WebTOC Si No No Si No No No Software de código abierto
Dreamweaver Si Si No Si No No No Software propietario
SGMapper Si Si No No No Si No No disponible
UriGraph Si No No No No Si Si No disponible
CmapTools Si Si Si No No No No Software de distribución
gratuita con código cerrado
gOOWS Si No No No No No Si Software de código cerrado
TouchGraph Si Si No No No Si No Software con versiones de código
abierto y cerrado Personal Brain Si Si No No No No No Software de
distribución gratuita con código
cerrado OntoWebber Si No No No No Si Si Software de código
abierto Herramienta
propuesta Si Si Si Si Si Si Si Software de código
abierto
Capítulo 4. Análisis y diseño de la solución
El presente capítulo describe la solución propuesta a la problemática estudiada en este trabajo. Se detalla la investigación realizada para encontrar los patrones, conceptos y relaciones que conforman la ontología del dominio de educación que se utiliza en la metodología para la construcción de sitios Web.
Capítulo 4. Análisis y diseño de la solución
Página 39
4.1. Descripción general de la solución propuesta
La solución que se plantea para la presente investigación se describe a continuación.
Se propone como hipótesis que a través de una metodología de construcción de sitios Web basada en principios de ontologías, se pueda agregar semántica a la estructura del sitio para que éste sea más fácil de comprender. El proceso de solución se compone de tres fases:
a) El análisis de un caso de estudio (una muestra de sitios Web de escuelas y centros de
investigación)
b) La definición y formalización de la metodología de construcción del sitio Web,
c) La implementación de un editor de estructuras de sitios Web, basado en la
metodología propuesta. El editor debe permitir al arquitecto establecer los tipos de
relaciones entre los elementos que constituyen el sitio, de tal manera que se asegure el
cumplimiento de las pautas de construcción proporcionadas por la metodología.
Dichas pautas dependen del tipo de relación establecida inicialmente.
4.2. Desarrollo de una metodología para definir estructuras de sitios Web basada en diseño de ontologías
La metodología de solución propuesta requirió de un trabajo de investigación con un análisis de sitios Web del dominio de educación. Aunque se trabajó sobre un dominio específico, se espera que esta propuesta sea adaptable y pueda aplicarse a otros dominios de sitios Web.
Los pasos a seguir que conforman dicha metodología se listan a continuación y se
explica la manera en que se realizaron.
4.2.1. Estudio de los dominios de trabajo
4.2.1.1. Análisis de sitios Web de dominio educación (edu)
Para llevar a cabo el análisis de dominio del tipo académico se seleccionó una muestra de sitios en base a un valor de agrupación. Originalmente se deseaba tomar como valor el tamaño de la población estudiantil, sin embargo, no fue posible utilizar este dato ya que no es público. Como una segunda opción se eligió el tipo de institución educativa, tomando en consideración dos tipos: institutos tecnológicos y centros de investigación. A pesar del factor de selección anterior, se limitó la muestra a veinte sitios de este tipo, por la amplitud del dominio de trabajo.
Capítulo 4. Análisis y diseño de la solución
Página 40
A partir del análisis anterior se obtuvieron los modelos de organización, tipos de enlaces y patrones que sigue la estructura de los sitios Web, para utilizarlos en la formalización de una ontología, como base para la definición de la metodología, y el diseño del editor que la implemente. A continuación se muestra cada paso del análisis realizado.
Conjunto de instituciones analizadas
La siguiente tabla muestra el conjunto de sitios Web que se estudiaron dentro del dominio de educación.
Tabla 4.1. Conjunto de sitios Web analizados
No. Nombre de la institución Página Tipo de sitio
1 Centro de Investigación Científica y de Educación Superior de Ensenada (CICESE)
http://www.cicese.mx/ Centro de Investigación
2 Centro de Investigación en Computación, IPN
http://www.cic.ipn.mx/
Centro de Investigación
3 Centro de Investigación en Matemáticas, A. C.
http://www.cimat.mx/
4 Centro de Investigación y Asistencia en Tecnología y Diseño del estado de Jalisco (CIATEJ)
http://www.ciatej.net.mx/ Centro de Investigación
5 Centro de Investigaciones Biológicas del Noroeste, S. C. (CIBNOR)
http://www.cibnor.mx/ecibnor.php Centro de Investigación
6 Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional (CINVESTAV)
http://www.cinvestav.mx/ Centro de investigación
7 Centro de Investigación y Docencia Económicas (CIDE)
http://www.cide.edu/ Centro de investigación
8 Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)
http://www.cenidet.edu.mx Centro de investigación
9 División Académica de Economía, Derecho y Ciencias Sociales, ITAM
http://daedcs.itam.mx/
Centro de Investigación
10 Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE)
http://www.inaoep.mx Centro de investigación
11 Instituto Tecnológico de Acapulco (ITA)
http://www.it-acapulco.edu.mx Instituto Tecnológico
12 Instituto Tecnológico de Apizaco
http://www.itapizaco.edu.mx Instituto Tecnológico
13 Instituto Tecnológico del Altiplano de Tlaxcala
http://italtiplanotlaxcala.edu.mx Instituto Tecnológico
Capítulo 4. Análisis y diseño de la solución
Página 41
14 Instituto Tecnológico de Celaya (ITC)
http://www.itc.mx/itc/scripts/index. Php
Instituto Tecnológico
15 Instituto Tecnológico de Chihuahua
http://www.itchihuahua.edu.mx/ Instituto Tecnológico
16 Instituto Tecnológico de Chilpancingo (ITCHILPANCINGO)
http://www.itchilpancingo.edu.mx/ principal/servlet/hinicio
Instituto Tecnológico
17 Instituto Tecnológico de Ciudad Madero
http://www. itcd.edu.mx/ Instituto Tecnológico
18 Instituto Tecnológico de Minatitlán (ITMINA)
http://www.itmina.edu.mx Instituto Tecnológico
19 Instituto Tecnológico de Morelia
http://www.itmorelia.edu.mx Instituto Tecnológico
20 Laboratorio Nacional de Informática Avanzada (LANIA)
http://www.lania.mx Centro de Investigación
Tras analizar la muestra de sitios Web se encontró que presentaban semejanzas en el
tipo de conceptos y estructuras, por lo que no se consideró necesario extender el análisis a más sitios, sobre todo por limitaciones de tiempo.
4.2.1.2. Estructura de páginas
Los sitios Web incluyen varios sistemas de navegación definidos en el capítulo 2. La identificación de los sistemas de navegación permite conocer la estructura del sitio, separando los componentes de tipo jerárquico y de hipertexto que se encuentran en las páginas.
Capítulo 4. Análisis y diseño de la solución
Página 42
Figura 4.1. Página principal del CINVESTAV
Dentro de las páginas principales de la mayoría de los sitios se observaron conjuntos
de enlaces concentrados en tres grupos (figura 4.1).
A) Conjunto primario de navegación:
Este conjunto está conformado por elementos descriptivos y de organización, como: información sobre la institución, accesos a la oferta educativa (posgrados o carreras) y líneas de investigación, así como organigramas de los departamentos de la institución.
Capítulo 4. Análisis y diseño de la solución
Página 43
Figura 4.2. Ejemplo de estructura jerárquica entre la página principal del CINVESTAV y elementos del
grupo de navegación primario
B) Conjunto secundario de navegación:
Constituido de enlaces hacia eventos, noticias o cursos. En este conjunto aparecen las convocatorias para cursar estudios en las instituciones educativas, enlaces a talleres y congresos, enlaces de interés y otras actividades.
Figura 4.3. Enlaces del conjunto secundario de navegación
Capítulo 4. Análisis y diseño de la solución
Página 44
C) Conjunto terciario de navegación
Conformado por enlaces hacia el correo institucional, mapa del sitio, página principal, encuestas y buscadores, entre otros.
4.2.2. Construcción de una ontología del dominio de educación
Del análisis anterior se obtuvieron patrones de cómo los elementos se distribuyen en los sitios Web. Los patrones pueden formalizarse en una ontología que permita catalogar los conceptos en clases y definir las relaciones entre las clases y las instancias correspondientes a las clases. Éstas se mapean directamente como las páginas que forman la estructura del sitio Web.
4.2.2.1. Identificación del propósito de la ontología
Los sitios Web poseen un vocabulario específico, de acuerdo al dominio al que pertenecen, siendo en este caso el dominio de educación (Dominio de nivel superior EDU). Sin embargo y, a pesar de que existen conceptos comunes entre los sitios analizados, es también frecuente encontrar sinónimos o términos que varían de acuerdo al tipo de institución educativa, debido a cuestiones propias del idioma.
Lo anterior deriva en definiciones del vocabulario de la estructura del sitio poco consistentes y en el establecimiento de nexos existentes entre los conceptos del dominio que no expresan la naturaleza de la relación. Es por ello que resulta importante reducir los problemas de comprensión de la estructura del sitio Web.
Para eliminar estas ambigüedades se requiere:
Identificar los conceptos propios del dominio de trabajo que son utilizados por los
usuarios y proporcionar un vocabulario compartido, disminuyendo las diferencias y
confusión de terminología utilizada para denominar a los elementos que conforman el
sitio Web.
Identificar las posibles relaciones entre los conceptos del dominio.
Brindar restricciones que puedan ser aplicadas al contexto que integran los conceptos
y relaciones que los enlazan, así como sus sinónimos correspondientes.
4.2.2.2. Identificación de conceptos del dominio
En este apartado se identifican los conceptos y las relaciones en el dominio de educación. Posteriormente se producen las definiciones no ambiguas para los conceptos. Una definición no ambigua permite diferenciar los conceptos, evitando la confusión de términos o interpretaciones erróneas.
Capítulo 4. Análisis y diseño de la solución
Página 45
4.2.2.3. Creación de la taxonomía de clases
Los conceptos obtenidos del dominio de trabajo pueden organizarse hasta obtener una taxonomía que los agrupe en clases y subclases, descartando aquellos elementos que son propiamente las instancias. Finalmente la taxonomía de clases de la ontología se muestra en la figura 4.4 y se describe posteriormente cada una, listando algunos tipos de instancias.
Figura 4.4. Diagrama de clases de la ontología
En la tabla 4.2 se definen las clases de la taxonomía generada para el dominio de educación del caso específico analizado en esta investigación (la identación indica una relación de clase-subclase). Aunque sólo las clases correspondientes a las hojas de la taxonomía son tomadas en cuenta para la especificación de relaciones entre conceptos del dominio.
class Class Model
Documento
+ Conectividad: char
+ Temporalidad: char
+ TipoEntidad: char
InformaciónProductoServ icio
Serv icio interno Serv icio externo Estructura
Unidad
organizacional
Organización
funcionamiento
Descripción Trámite Suceso Personal
Estudiante TrabajadorDescripción
física
Descripción
abstracta
Capítulo 4. Análisis y diseño de la solución
Página 46
Tabla 4.2. Definición de clases de la taxonomía
Documento: un documento es la clase más genérica, es decir, a partir de ella se desprenden las demás clases de la ontología. El documento representa cualquier tipo de elemento que pueda conformar un sitio Web, por ejemplo: una página html, una imagen gif o un archivo de texto pdf.
Información: documento para compartir o difundir datos.
Descripción: proporcionan al usuario un panorama general de la institución.
DescripciónAbstracta: un documento de descripción se refiere a elementos de presentación de la institución. Pueden contender detalles históricos, definición del perfil de la institución, objetivos, etc.
DescripciónFísica: elemento que muestra la disposición de los recursos de una institución.
Estructura: documentos referentes a la manera en que se conforma la institución organizacionalmente.
OrganizaciónFuncionamiento: muestra la administración o coordinación de un proceso de manera formal.
UnidadOrganizacional: espacio de trabajo o unidad administrativa de la institución. Se identifica por las funciones que lleva a cabo, el conjunto de responsabilidades que asume o por identificar a una agrupación.
Personal: tipo de documento que contiene información sobre una entidad animada.
Estudiante: dentro de la clase Personal, la cual aloja información sobre un estudiante de la institución educativa.
Trabajador: dentro de la clase Personal, la cual aloja información sobre un empleado de la institución educativa.
Trámite: indica la consecución de pasos para desarrollar una tarea de interés para los estudiantes o el personal de la institución. Los trámites suelen ser actividades obligatorias.
Suceso: documento informativo cuyo tiempo de vida tiene una duración establecida. Se refiere a aquellos componentes que no son permanentes y viven mientras poseen carácter de importancia en el sitio web o en una temporada específica con respecto a un acontecimiento relevante.
Producto: representa un objeto que percibe un consumidor o un conjunto de beneficios o satisfacciones. En los centros de investigación, los productos son el resultado de la investigación científica.
Servicio: describe procesos, algunas veces dinámicos, que requieren introducción de datos por parte del usuario para obtener como resultado un componente que depende de los datos proporcionados. Estos servicios son regularmente prestaciones que cubren un tipo de necesidad del usuario.
ServicioInterno: tipo de servicio que se ofrece al personal o estudiantes con respecto a la institución.
ServicioExterno: servicios ofrecidos por la institución a otras organizaciones.
Capítulo 4. Análisis y diseño de la solución
Página 47
4.2.2.4. Atributos de las clases de la ontología
Conectividad: tipo de enlace que se puede establecer a partir de la página que
pertenece a ésta clase. Las variantes de este valor son las siguientes:
o Enlace: la página puede contener un conjunto de enlaces hacia otros elementos
del sitio Web.
Uniforme: conjunto de enlaces que se refieren a una misma temática.
Mixto: diversas agrupaciones de enlaces de distinta temática o tipo.
o Simple: la página es considerada una hoja del sitio Web, es decir, que no
contiene enlaces que estructuralmente lleven hacia otros elementos.
Existencia: se refiere al periodo de vida estimado para una página que pertenece a
ésta clase y sus valores son los siguientes:
o Temporal: una página con un periodo de vida determinado.
o Permanente: aquel elemento que permanece en el tiempo, aun cuando se
realicen cambios sobre él.
Tipo de entidad: tomando en cuenta que existen páginas con niveles compositivos de
tipo concreto; que representan elementos sólidos, compactos o materiales, precisos,
determinados y sin vaguedad; o elementos abstractos que significan alguna cualidad
con exclusión del sujeto. Sus valores son los siguientes:
o Espacio-material: con un nivel compositivo concreto.
o Simbólica: con un nivel compositivo abstracto.
4.2.2.5. Definición de clases de la taxonomía Las clases listadas a continuación son las hojas de la taxonomía de clases. Entre estas clases existe un conjunto de relaciones que son aplicables a sus ejemplares y que se formalizan en la sección posterior.
Tabla 4.3. Definición de la clase Descripción abstracta
Clase: Descripción abstracta
Superclase: Descripción. Definición: Elementos de presentación de la institución. Pueden contender detalles
históricos, definición del perfil de la institución, objetivos, etc. Acción de representar a alguien o algo por medio del lenguaje, refiriendo o explicando sus distintas partes, cualidades o circunstancias.
Instancias: Presentación, misión, visión, objetivo, historia, ubicación, acerca de, servicios. Atributo: Tipo de entidad: simbólica.
Conectividad: simple/enlace. Existencia: permanente.
Capítulo 4. Análisis y diseño de la solución
Página 48
Tabla 4.4. Definición de la clase Descripción física
Clase: Descripción física
Superclase: Descripción. Definición: Elemento que muestra la disposición de los recursos de la institución. Instancias: Directorio, infraestructura, organigrama institucional. Atributo: Tipo de entidad: espacio-material.
Conectividad: simple/enlace. Existencia: permanente.
Tabla 4.5. Definición de la clase Estudiante
Clase: Estudiante
Superclase: Personal. Definición: Contiene información sobre la persona que cursa estudios en una institución
educativa. Instancias: Estudiante de posgrado, estudiante de licenciatura. Atributo: Tipo de entidad: espacio-material.
Conectividad: simple. Existencia: temporal.
Tabla 4.6. Definición de la clase Organización funcionamiento
Clase: Organización funcionamiento
Superclase: Estructura. Definición: Elemento que muestra la administración o coordinación de un proceso de
manera formal. Instancias: Reglamento, plan de estudios. Atributo: Tipo de entidad: simbólica.
Conectividad: simple. Existencia: permanente.
Tabla 4.7. Definición de la clase Producto
Clase: Producto
Superclase: Documento. Definición: Representa un objeto que percibe un consumidor o un conjunto de beneficios
o satisfacciones. En los centros de investigación, los productos son el resultado de la investigación científica.
Instancias: Tesis, publicación. Atributo: Tipo de entidad: espacio-material.
Conectividad: simple. Existencia: permanente.
Tabla 4.8. Definición de la clase Servicio externo
Clase: Servicio externo
Superclase: Servicio. Definición: Servicios ofrecidos por la institución a otras organizaciones. Instancias: Capacitación, consultoría, bolsa de trabajo.
Capítulo 4. Análisis y diseño de la solución
Página 49
Atributo: Tipo de entidad: simbólica. Conectividad: simple. Existencia: permanente.
Tabla 4.9. Definición de la clase Servicio interno
Clase: Servicio interno
Superclase: Servicio. Definición: Tipo de servicio que se ofrece al personal o estudiantes con respecto a la
institución. Instancias: Búsqueda, consulta bibliográfica, correo electrónico, kardex, centro de
idiomas. Atributo: Tipo de entidad: simbólica.
Conectividad: simple. Existencia: permanente.
Tabla 4.10. Definición de la clase Suceso
Clase: Suceso
Superclase: Información. Definición: Acontecimiento relevante o actividad que posee carácter de importancia en
una temporada específica. Instancias: Noticia, evento, curso. Atributo: Tipo de entidad: simbólica.
Conectividad: simple. Existencia: temporal.
Tabla 4.11. Definición de la clase Trabajador
Clase: Trabajador
Superclase: Personal. Definición: Contiene información sobre la persona que labora en un organismo,
dependencia o institución. Instancias: Académico, administrativo. Atributo: Tipo de entidad: espacio-material.
Conectividad: simple. Existencia: temporal.
Tabla 4.12. Definición de la clase Trámite
Clase: Trámite
Superclase: Información. Definición: Consecución de pasos para desarrollar una tarea de interés para los
estudiantes o el personal de la institución. Los trámites suelen ser actividades obligatorias.
Instancias: Admisión, titulación, beca, servicio social, residencia profesional, actividad extraescolar.
Atributo: Tipo de entidad: simbólica. Conectividad: simple. Existencia: permanente.
Capítulo 4. Análisis y diseño de la solución
Página 50
Tabla 4.13. Definición de la clase Unidad organizacional
Clase: Unidad organizacional
Superclase: Estructura. Definición: Espacio de trabajo o unidad administrativa de la institución. Se identifica por
las funciones que lleva a cabo, el conjunto de responsabilidades que asume o por identificar a una agrupación.
Instancias: Departamento, línea de investigación, posgrado, principal, personas, bienes. Atributo: Tipo de entidad: simbólica.
Conectividad: enlace. Existencia: permanente.
4.2.2.6. Establecimiento de relaciones de la ontología
Figura 4.5. Conjunto de relaciones
La identificación de relaciones para la creación de la ontología no es una tarea sencilla, ya que un sitio Web utiliza entidades abstractas, que resultan difíciles de relacionar. Una página Web es capaz de conceptualizar un objeto que no posee representación física en el mundo real, ejemplo de ello son conceptos como: acerca de o enlace de interés.
Estos conceptos no tienen propiedades físicas que ayuden a identificarlos como partes, todos, generalizaciones o especializaciones de otros elementos o la manera en que interactúan entre ellos mismos. Dichos elementos le permiten a la lingüística o a enfoques como UML definir relaciones.
Es por ello que las relaciones entre los conceptos del dominio de educación, aplicadas en esta investigación, conjuntan propiedades y tipos encontrados en la literatura. Primero se
class System
Léxica
Léxica
paradigmática
Léxica
sintagmática
Meronimia
Meronimia
Canónica-
Canónica
Meronimia
Canónica-
Facultativ a
Meronimia
Facultativ a-
Canónica
Meronimia
Facultativ a-
Facultativ a
Meronimia
Colección-
Miembro
Meronimia Grupo-
Miembro
Meronimia E
Meronimia F
Meronimia G
Meronimia H
Meronimia I Meronimia K Meronimia L
Meronimia M
Meronimia N Meronimia A Meronimia B Meronimia D Meronimia C
Hiperonimia
Topológica
Produce Registra
Capítulo 4. Análisis y diseño de la solución
Página 51
tomó como base las relaciones léxicas (sintagmáticas y paradigmáticas), así como las propuestas por Cruse [CRUSE 1986] aplicando propiedades de la mereología y UML.
Las relaciones resultantes se describen a continuación y se resumen en la figura 4.5.
(A) Meronimia Facultativa-Facultativa: esta meronimia se aplica a todos y partes que
están unidos de manera opcional, pues en muchos casos el concepto que representa a la parte está compartido, es decir que puede aparecer en varias secciones del sitio Web. Para la existencia de la relación es necesario unir como máximo un todo con una única parte del conjunto de posibles partes.
El todo puede tener a la parte de manera opcional.
La parte puede pertenecer al todo de manera opcional.
La parte es un concepto que puede ser compartido, apareciendo en diversas partes del
sitio Web.
De existir una parte dentro del todo, no puede existir otro elemento de la misma clase
como parte del todo.
Al eliminar el todo se elimina siempre la parte.
Al eliminar la parte no se elimina el todo.
No es posible crear un enlace desde la parte hacia el todo de manera dinámica.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.14 (definidas en 4.2.2.5):
Tabla 4.14. Dominio y rango para la relación (A) Meronimia Facultativa-Facultativa
Dominio Rango
Unidad organizacional Organización funcionamiento Unidad organizacional Descripción abstracta Unidad organizacional Descripción física Unidad organizacional Unidad organizacional
(B) Meronimia Facultativa-Facultativa: esta meronimia se aplica a todos y partes que
están unidos de manera opcional, pues en muchos casos el concepto que representa a la parte está compartido, es decir que puede aparecer en varias secciones del sitio Web. Para la existencia de la relación es posible unir un todo con una infinidad de partes de la misma clase.
El todo puede tener a la parte de manera opcional.
La parte puede pertenecer al todo de manera opcional.
La parte es un concepto que puede ser compartido, apareciendo en diversas partes del
sitio Web.
De existir una parte dentro del todo, es posible que existan n número de elementos de
la misma clase como parte del todo.
Al eliminar el todo se elimina siempre la parte.
Al eliminar la parte no se elimina el todo.
Es posible crear enlace dinámicamente hacia nuevas partes.
Capítulo 4. Análisis y diseño de la solución
Página 52
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.15 (definidas en 4.2.2.5):
Tabla 4.15. Dominio y rango para la relación (B) Meronimia Facultativa-Facultativa
Dominio Rango
Descripción abstracta Organización funcionamiento
(C) Meronimia Grupo-Miembro: esta meronimia es aplicable a documentos que
representan seres vivos que conforman organizaciones o grupos.
El todo es un grupo u organización.
La parte es un individuo que pasa a formar parte de un grupo.
Un individuo es exclusivo de un grupo, es decir, que no puede pertenecer a diversos
grupos al mismo tiempo.
Un grupo puede conformarse de n número de elementos de la misma clase.
Un grupo no puede eliminarse mientras existan miembros dentro de él.
Al eliminar un miembro, el grupo permanece.
Es posible crear enlaces a nuevos miembros del grupo.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.16 (definidas en 4.2.2.5):
Tabla 4.16. Dominio y rango para la relación (C) Meronimia Grupo-Miembro:
Dominio Rango
Unidad organizacional Estudiante Unidad organizacional Trabajador
(D) Meronimia Colección-Miembro: esta meronimia es aplicable a documentos que representan elementos inanimados que conforman colecciones de objetos de cierto tipo.
El todo es una colección.
La parte es un objeto que pasa a formar parte de la colección.
Un objeto pertenece de manera obligatoria a una colección, es decir, la colección debe
tener como parte a un elemento de la clase miembro.
Una colección puede conformarse de n número de miembros de la misma clase,
teniendo por lo menos uno.
Una colección no puede eliminarse mientras existan miembros dentro de ella.
Al eliminar un miembro, la colección permanece.
Es posible crear enlaces a nuevos miembros de la colección.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.17 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 53
Tabla 4.17. Dominio y rango para la relación (D) Meronimia Colección-Miembro
Dominio Rango
Unidad organizacional Producto
(E) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que
están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera obligatoria.
La parte existe si existe el todo, es decir, hay una dependencia existencial entre los dos
elementos.
Es necesario que existan la parte en el todo y no es posible que exista otro elemento de
la misma clase como parte del todo.
Al eliminar el todo se elimina siempre la parte.
Al eliminar la parte se elimina siempre el todo.
No es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.18 (definidas en 4.2.2.5):
Tabla 4.18. Dominio y rango para la relación (E) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Organización funcionamiento
(F) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera obligatoria.
La parte pertenece de manera obligatoria al todo, es decir, el todo debe tener como
parte a un elemento de la clase.
Al eliminar el todo se elimina siempre la parte.
Al eliminar la parte no se elimina el todo.
Debe existir un elemento de la clase como parte del todo y pueden existir n número de
elementos de esta clase como partes del todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.19 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 54
Tabla 4.19. Dominio y rango para la relación (F) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Unidad organizacional
(G) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que
están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo contiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera obligatoria.
La parte debe tener como todo a un elemento de la clase, de manera obligatoria y no
puede pertenecer a otro tipo de elementos de otras clases.
Debe existir un elemento de la clase como parte del todo y pueden existir n número de
elementos de esta clase como partes del todo.
No es posible eliminar un todo sin antes eliminar las partes que lo conforman.
Al eliminar la parte no se elimina el todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.20 (definidas en 4.2.2.5):
Tabla 4.20. Dominio y rango para la relación (G) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Descripción física
(H) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera obligatoria.
La parte pertenece de manera obligatoria al todo, es decir, el todo debe tener como parte
a un elemento de la clase.
Debe existir un elemento de la clase como parte del todo y pueden existir sólo un
elemento de esta clase como partes del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
No es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.21 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 55
Tabla 4.21. Dominio y rango para la relación (H) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Descripción abstracta
(I) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que
están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte pertenece al todo de manera obligatoria.
La parte p
ertenece de manera exclusiva al todo, es decir, el todo debe ser el único en tener como
parte a un elemento de la clase.
Si existe un elemento de la clase como parte del todo, pueden existir n número de
elementos de esta clase como partes del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.22 (definidas en 4.2.2.5):
Tabla 4.22. Dominio y rango de la relación (I) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Unidad organizacional
(J) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera obligatoria.
La parte pertenece de manera obligatoria al todo, es decir, el todo debe tener como parte
a un elemento de la clase.
Debe existir un elemento de la clase como parte del todo y puede existir sólo un
elemento de esta clase como partes del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.23 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 56
Tabla 4.23. Dominio y rango para la relación (J) Meronimia Canónica-Canónica
Dominio Rango
Unidad organizacional Descripción abstracta
(K) Meronimia Canónica-Facultativa: esta meronimia se aplica a todos obligatorios
con partes opcionales, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera opcional.
Si existe, la parte pertenece de manera obligatoria al todo, es decir, el todo debe tener
como parte a un elemento de la clase.
Debe existir un elemento de la clase como parte del todo y puede existir n número de
elementos de esta clase como partes del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
No es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.24 (definidas en 4.2.2.5):
Tabla 4.24. Dominio y rango para la relación (K) Meronimia Canónica-Facultativa
Dominio Rango
Descripción abstracta Descripción abstracta
(L) Meronimia Canónica-Facultativa: esta meronimia se aplica a todos obligatorios con partes opcionales, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera opcional.
Si existe, la parte pertenece de manera obligatoria al todo, es decir, el todo debe tener
como parte a un elemento de la clase.
Debe existir un elemento de la clase como parte del todo y puede existir sólo un
elemento de esta clase como parte del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
No es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.25 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 57
Tabla 4.25. Dominio y rango para la relación (L) Meronimia Canónica-Facultativa
Dominio Rango
Descripción abstracta Descripción física
(M) Meronimia Canónica-Facultativa: esta meronimia se aplica a todos obligatorios
con partes opcionales, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera obligatoria.
La parte puede pertenecer al todo de manera opcional.
Si existe, la parte pertenece de manera obligatoria al todo, es decir, el todo debe tener
como parte a un elemento de la clase.
Debe existir un elemento de la clase como parte del todo y puede existir n número de
elementos de esta clase como partes del todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.26 (definidas en 4.2.2.5):
Tabla 4.26. Dominio y rango para la relación (M) Meronimia Canónica-Facultativa
Dominio Rango
Unidad organizacional Descripción física
(N) Meronimia Facultativa -Canónica: esta meronimia se aplica a todos opcionales con partes obligatorias, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.
El todo tiene a la parte de manera opcional.
La parte pertenece al todo de manera obligatoria.
La parte pertenece de manera exclusiva al todo, es decir, el todo debe ser el único en
tener como parte a un elemento de la clase.
Si existe una parte de la clase para el todo, pueden existir n número de partes de la
misma clase para el todo.
Al eliminar el todo se elimina la parte.
Al eliminar la parte no se elimina el todo.
Es posible crear enlaces dinámicamente hacia nuevas partes.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.27 (definidas en 4.2.2.5):
Capítulo 4. Análisis y diseño de la solución
Página 58
Tabla 4.27. Dominio y rango para la relación (N) Meronimia Facultativa -Canónica
Dominio Rango
Unidad organizacional Trámite
Topológica: esta relación aplica entre sustantivos que permanecen unidos por un
tiempo determinado.
El elemento del rango puede enlazarse dinámicamente hacia el dominio.
Al desaparecer el elemento del rango no se elimina el elemento del dominio.
Pueden existir diferentes elementos de la clase del rango en el elemento de la clase del
dominio.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.28 (definidas en 4.2.2.5):
Tabla 4.28. Dominio y rango para la relación Topológica
Dominio Rango
UnidadOrganizacional Suceso
Produce: indica que existen dos entidades donde una lleva a cabo la acción de producir y la otra es el resultado de la acción.
El elemento del dominio puede enlazarse dinámicamente hacia el elemento del rango
y viceversa.
Al desaparecer el elemento del dominio no es necesario que el elemento del rango
desaparezca.
Al desaparecer el elemento del rango no es necesario que el elemento del dominio
desaparezca.
Un elemento del dominio puede relacionarse con varios elementos del rango y
viceversa.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.29 (definidas en 4.2.2.5):
Tabla 4.29. Dominio y rango para la relación Produce
Dominio Rango
Trabajador Producto
Registra: indica que existen dos entidades donde una lleva a cabo la acción de registrar y la otra es el elemento que se registra.
Capítulo 4. Análisis y diseño de la solución
Página 59
El elemento del dominio puede enlazarse dinámicamente hacia el elemento del rango
y viceversa.
Al desaparecer el elemento del dominio no es necesario que el elemento del rango
desaparezca.
Al desaparecer el elemento del rango no es necesario que el elemento del dominio
desaparezca.
Si desaparecen todos los elementos del rango, no es lógico que exista en elemento del
dominio.
Un elemento del dominio puede relacionarse con diferentes elementos del rango.
Un elemento del rango puede relacionarse con diferentes elementos del dominio.
El dominio y rango de esta relación están dados por las siguientes clases que se
muestran en la tabla 4.30 (definidas en 4.2.2.5):
Tabla 4.30. Dominio y rango para la relación Registra
Dominio Rango
DescripciónFísica Trabajador
Capítulo 4. Análisis y diseño de la solución
Página 60
Tabla 4.31. Conjunto de propiedades para relaciones meronímicas
Tipo de relación Multiplicidad Propagación
de borrado Comportamiento temporal
Dominio y rango Propiedad secundaria
(A) Meronimia facultativa-facultativa
0..1, 0..1 Cascada-Enlace
Dinámico-Estático UnidadOrganizacional-OrganizaciónFuncionamiento UnidadOrganizacional-DescripciónAbstracta UnidadOrganizacional-DescripciónFísica UnidadOrganizacional-UnidadOrganizacional
Concepto compartido
(B) Meronimia facultativa-facultativa
0..1, 0..* Cascada-Enlace
Dinámico-Dinámico
DescripciónAbstracta-OrganizaciónFuncionamiento
Concepto compartido
(C) Meronimia grupo-miembro
1,* Restringido-Enlace
Dinámico-Estático UnidadOrganizacional-Estudiante UnidadOrganizacional-Trabajador
Parte exclusiva
(D)Meronimia colección-miembro
1, 1..* Restringido-Enlace
Dinámico-Estático UnidadOrganizacional-Producto Parte obligatoria
(E) Meronimia canónica-canónica
1,1 Cascada-Cascada
Estático-Estático UnidadOrganizacional-OrganizaciónFuncionamieto
Dependencia existencial
(F) Meronimia canónica-canónica
1, 1..* Cascada-Enlace
Dinámico-Estático UnidadOrganizacional-UnidadOrganizacional DescripciónAbstracta-ServicioInterno DescripciónAbstracta-ServicioExterno
Parte obligatoria
(G) Meronimia canónica-canónica
1, 1..* Restringido-Enlace
Dinámico-Dinámico
UnidadOrganizacional-DescripciónFísica
Todo obligatorio
(H) Meronimia canónica-canónica
1,1 Cascada-Enlace
Estático-Estático UnidadOrganizacional-DescripciónAbstracta
Parte obligatoria
(I) Meronimia canónica-canónica
1, 0..* Cascada-Enlace
Dinámico-Estático UnidadOrganizacional-UnidadOrganizacional
Parte exclusiva
(J) Meronimia canónica-canónica
1,1 Cascada-Enlace
Estático-Estático UnidadOrganizacional-DescripciónAbstracta
Parte obligatoria
Capítulo 4. Análisis y diseño de la solución
Página 61
(K) Meronimia canónica-facultativa
0..1, 1..* Cascada-Enlace
Estático-Estático DescripciónAbstracta-DescripciónAbstracta
Parte obligatoria
(L) Meronimia canónica-facultativa
0..1, 1 Cascada-Enlace
Estático-Estático DescripciónAbstracta-DescripciónFísica
Parte obligatoria
(M)Meronimia canónica-facultativa
0..1, 1..* Cascada-Enlace
Dinámico-Estático DescripciónFísica- UnidadOrganizacional
Parte obligatoria
(N) Meronimia facultativa-canónica
1, 0..* Cascada-Enlace
Dinámico-Estático UnidadOrganizacional-Trámite Parte exclusiva
Topológica 1, 0..* Cascada-Enlace
Dinámico-Dinámico
UnidadOrganizacional-Suceso Ninguna
Registra 1, 0..* Enlace-Enlace
Dinámico-Estático Trabajador-DescripciónFísica Ninguna
Produce 1..*, 1..* Enlace-Enlace
Dinámico-Estático Estudiante-Producto Trabajador-Producto
Ninguna
Capítulo 4. Análisis y diseño de la solución
Página 62
4.3. Editor de estructuras de sitios Web
Para construir el editor se realizó un análisis de requerimientos previo, que refleja los problemas y necesidades del usuario.
4.3.1. Análisis de requerimientos del usuario
Se identificaron dos posibles situaciones que pueden darse entre el usuario y la herramienta:
Crear un sitio Web nuevo: implica la construcción total de la estructura del sitio.
Editar un sitio Web construido previamente con la herramienta propuesta: se refiere a un sitio Web cuya estructura fue construida utilizando el editor propuesto.
4.3.2. Arquitectura general de la herramienta y descripción de las funciones
En esta sección se muestra la arquitectura general del software y se describen los módulos que se consideran necesarios para el desarrollo de la herramienta. Las funciones obtenidas son resultado del análisis de requerimientos.
Figura 4.6. Arquitectura general del editor EDWEB
class Domain Objects
Editor manual de
grafos Verificador
Generador de
estructura
Panel de
v isualización de
grafos
Archiv os
Usuario
Buscar XML
Retorna XML
Entrada
XML a verificar
XML verificado
XML para creación de estructuraXML a interpretar Grafo del XML
Archivos para almacenamiento
Salida
Capítulo 4. Análisis y diseño de la solución
Página 63
Crear grafo del sitio Web: esta tarea está soportada por la aplicación LinkBrowser de
Touchgraph, sin embargo se realizaron modificaciones al código para crear grafos con
nodos etiquetados a partir de un árbol de conceptos que deberá ser formado
automáticamente a partir de un archivo OWL de la ontología. De la misma manera se
realizaron las modificaciones pertinentes para obtener aristas etiquetadas con las
relaciones establecidas en la ontología.
Crear archivo XML a partir de un grafo: con LinkBrowser es posible crear archivos
descriptivos, por lo que se ha hecho una modificación para almacenar los nombres en
las aristas del grafo al archivo XML de la estructura.
Generar grafo a partir de un archivo XML: se realizaron pequeñas modificaciones
para crear el grafo con aristas etiquetadas.
Generar estructura del sitio Web: la herramienta LinkBrowser no es capaz de crear
páginas en blanco del sitio Web, por lo que esta funcionalidad fue añadida en el editor
de sitios.
Crear reporte de errores: se agregó un módulo de análisis del grafo dibujado,
incluyendo los errores existentes al momento de crearlo, como la falta de relaciones
entre los conceptos.
Validar estructura del sitio Web: el editor debe proporcionar una manera de
identificar que los elementos de un grafo, que conforman el archivo XML del sitio
Web, están debidamente etiquetados.
4.3.3. Usuarios de la herramienta
1) Administrador del sitio Web
El administrador del sitio Web es conocido también como Webmaster. Se encarga de administrar el sitio Web, tal como su nombre lo indica. Entre sus tareas se encuentran la de crear y manejar la información y la organización de un sitio Web, de acuerdo al tamaño del mismo.
En sitios grandes se encarga de la supervisión del diseño del sitio, mientras que en
sitios pequeños lleva a cabo la creación y el mantenimiento.
2) Arquitecto de la información
Integra los componentes del sitio Web y la manera en que el usuario navegará de una página a otra.
Una de sus tareas es la de diseñar un mapa de sitio que muestre las secciones principales del sitio. Posteriormente, el IA17, se dedica a los detalles a nivel página y crea una serie de
17 Arquitecto de la Información, por sus siglas en inglés.
Capítulo 4. Análisis y diseño de la solución
Página 64
maquetas de la arquitectura de las páginas y esbozos de diseño18 que muestran el contenido y los elementos de navegación que componen cada página del sitio.
4.3.4. Limitaciones de la herramienta
El editor no tiene limitantes en cuanto al lenguaje de desarrollo o la plataforma, sin embargo, se debe establecer un ambiente adecuado de acuerdo al tipo de herramienta a desarrollar.
El producto se cataloga como un software de aplicación monopuesto, porque ayuda al
usuario con un solo rol de interacción a desarrollar tareas específicas.
La aplicación se ejecutará sobre un equipo local, sin el uso de servidores o conexiones
a red.
En cuanto a la aplicación del análisis, se utilizan relaciones estáticas. No es posible
definir nuevos tipos de relaciones, para llevar un control en las restricciones y la
manera en que se enlazan los nodos de los grafos.
Las validaciones son exclusivas a las relaciones definidas en el grafo, ya que no se
contempla contenido.
4.4. Diseño
Esta sección muestra los casos de uso de la herramienta y sus especificaciones.
4.4.1. Diagramas de casos de uso
Se muestran a continuación los diagramas de caso de uso del editor contemplados para este trabajo.
18 Las maquetas son borradores que muestran contenido y vínculos entre las páginas. Los esbozos se basan en las maquetas y son un primer intento por diseñar la interfaz de las páginas de nivel superior del sitio.
Capítulo 4. Análisis y diseño de la solución
Página 65
Figura 4.7. Casos de uso
Se observa como primer caso de uso la creación manual de un grafo que corresponde al caso en el que no existe un sitio previo y debe generarse desde el principio. Existe la posibilidad de que la creación del grafo incluya la visualización de una estructura previamente construida que se toma como base para el diseño.
La creación de un reporte de errores de una estructura implica que se creará primero
un grafo. Lo mismo ocurre en el caso de la generación de la estructura del sitio Web, que requiere a su vez de la creación de un reporte de errores.
Tabla 4.32. Propiedades de CU-1 Crear grafo del sitio Web
ID: CU-1 Crear grafo del sitio Web
Actores: Constructor del sitio Web. Descripción: Permite al usuario crear un nuevo grafo en el panel de edición. Precondiciones: 1. Debe cargarse la ontología requerida en la aplicación Poscondiciones: 1. Se obtiene un grafo con nodos y aristas etiquetadas Escenario de éxito 1: 1. Se abre la aplicación
2. Se carga la ontología requerida
Capítulo 4. Análisis y diseño de la solución
Página 66
3. El usuario toma un concepto de la lista de clases generada 4. El usuario selecciona una relación 5. Se genera una tripleta válida 6. Se repiten las acciones 3, 4 y 5 hasta que el usuario completa el grafo
Suposición: Supone que la ontología para esta aplicación ha sido creada.
Tabla 4.33. Propiedades de CU-2 Crear archivo XML a partir de un grafo
ID: CU-2 Crear archivo XML a partir de un grafo
Actores: Constructor del sitio Web. Descripción: Permite al usuario generar el archivo descriptivo de la estructura de un
sitio Web a partir de un grafo. Precondiciones: 1. Debe existir un grafo creado previamente
2. Todos los nodos y aristas del grafo deben estar etiquetados Poscondiciones: 1. Se almacena un archivo XML con una sección descriptiva para nodos y
otra para aristas Escenario de éxito 1: 1. Se crea un grafo previamente
2. Se selecciona del menú la opción de guardar un archivo como 3. El archivo es nombrado y almacenado
Escenario de éxito 2: 1. Se abre un archivo XML previamente creado 2. Se realizan modificaciones al grafo visualizado 3. Se selecciona del menú la opción de guardar un archivo como 4. El archivo es nombrado y almacenado
Suposición: Supone que cada nodo y arista han sido nombrados y que el grafo es coherente.
Tabla 4.34. Propiedades de CU-3 Generar grafo a partir de un archivo XML
ID: CU-3 Generar grafo a partir de un archivo XML
Actores: Constructor del sitio Web. Descripción: Permite al usuario visualizar un grafo a partir de un archivo XML que se
ha creado con anterioridad. Precondiciones: 1. Debe existir un archivo XML guardado Poscondiciones: 2. El grafo creado en el panel debe mostrar los nodos y aristas que no están
etiquetados. Escenario de éxito 1: 1. Se abre un archivo XML existente
2. Se muestra en el panel el grafo descrito por el archivo XML 3. Los nodos y aristas indefinidos se muestran en un color distinto al resto del grafo.
Suposición: El archivo XML utilizado mantiene la estructura del DTD.
Tabla 4.35. Propiedades de CU-4 Generar estructura del sitio Web
ID: CU-4 Generar estructura del sitio Web
Actores: Constructor del sitio Web. Descripción: Permite al usuario crear un conjunto de páginas basadas en un grafo
diseñado en la herramienta editor. Precondiciones: 1. Debe crearse y guardarse un archivo XML previamente
2. El archivo XML debe ser verificado para validar sus consistencia Poscondiciones: 1. Las páginas creadas deben contener los enlaces correspondientes hacia
Capítulo 4. Análisis y diseño de la solución
Página 67
otras páginas Escenario de éxito 1: 1. Se crea un archivo XML y se almacena
2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y se crea una carpeta con un conjunto de paginas enlazadas
Escenario de éxito 2: 1. Se crea un archivo XML y se almacena 2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y la carpeta ya existe 4. Se solicita la reescritura de la carpeta o el almacenamiento del archivo XML con otro nombre 5. Se almacena el archivo y se selecciona nuevamente la opción de generar estructura 6. La carpeta se crea exitosamente
Escenario de fracaso 1:
1. Se crea un archivo XML y se almacena 2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y la carpeta ya existe 4. Se solicita la reescritura de la carpeta o el almacenamiento del archivo XML con otro nombre 5. La carpeta no se sobreescribe y por tanto no se almacena
Suposición: La carpeta no existe o si existe se desea realizar cambios en ella y es posible sobreescribirla.
Tabla 4.36. Propiedades de CU-5 Crear reporte de errores
ID: CU-5 Crear reporte de errores
Actores: Constructor del sitio Web. Descripción: Proporcionar al usuario un elemento que le permita listar la serie de
errores encontrados en el grafo. Precondiciones: 1. Debe existir un grafo creado previamente Poscondiciones: 1. El reporte generado indica los nodos origen y destino de la arista
indefinida Escenario de éxito 1: 1. Se abre un archivo XML existente
2. Se selecciona del menú la opción de verificar grafo 3. En el panel del reporte se listan los nodos origen y destino de los enlaces con etiqueta indefinida
Escenario de éxito 2: 1. Se abre un archivo XML existente 2. Se selecciona del menú la opción de verificar grafo 3. En el panel del reporte aparece un mensaje que indica que el grafo está correctamente enlazado
Suposición: El archivo XML existe.
Tabla 4.37. Propiedades de CU-6 Validar estructura del sitio Web
ID: CU-6 Validar estructura del sitio Web
Actores: Constructor del sitio Web. Descripción: La validación ayuda al usuario a detectar posibles inconsistencias en el
grafo creado. Precondiciones: 1. El grafo está siendo modificado
2. El grafo ha sido previamente guardado Poscondiciones: 1. Se indica en el grafo, con un cambio de color, las aristas o nodos
etiquetados incorrectamente
Capítulo 4. Análisis y diseño de la solución
Página 68
2. Se indica la falta de etiquetas en los nodos Escenario de éxito 1: 1. Se abre un archivo XML existente
2. El grafo se visualiza en el panel de edición de grafos 3. Las aristas y nodos no etiquetados o etiquetados como indefinidos se observan en un tono de color distinto a los demás elementos del grafo
Escenario de éxito 2: 1. Se crea o se abre un archivo XML 2. Se desea realizar una modificación a una arista 3.La arista se etiqueta como indefinida 4. La arista indefinida se observa en un color diferente al resto del grafo
Suposición: El usuario, premeditadamente, nombra una arista como indefinida pues no conoce, por el momento, el tipo de relación existente entre dos elementos. El usuario elimina el nombre de un nodo en el archivo XML.
Capítulo 5. Implementación
El presente capítulo muestra la implementación de la ontología diseñada y describe la herramienta desarrollada para el trabajo de investigación. Dentro de este capítulo se observan los flujos de actividades de las tareas desarrolladas con el editor de sitios Web, así como las clases que se involucran en ellas.
Capítulo 5. Implementación
Página 70
5.1. Creación de la ontología con la herramienta Protégé
Para la implementación se tomó en cuenta la creación de la ontología para sitios Web del dominio de educación por medio de la herramienta Protégé. Protégé permite describir una jerarquía de clases de la ontología, sus atributos (slots) y las instancias de la base de conocimiento. El primer paso consiste en la creación de la jerarquía de clases, mostrada en la figura siguiente. Las clases se listan iniciando con la clase Documento y a partir de ella se crean elementos más particulares hasta llegar a las hojas de la jerarquía.
Figura 5.1. Jerarquía de clases
Para enlazar a dos individuos se crean relaciones binarias llamadas propiedades. Estas
propiedades son el equivalente a las relaciones encontradas en la etapa de desarrollo de la metodología.
Capítulo 5. Implementación
Página 71
Figura 5.2. Conjunto de propiedades
Existen dos tipos de propiedades principales: propiedades de objetos y propiedades
de tipo de dato. Las propiedades mostradas en la figura 5.1 son propiedades de objeto, pues enlazan a un individuo con otro, a diferencia de las de dato que enlazan un individuo con un símbolo o dato.
5.2. Desarrollo de la aplicación
5.2.1. Características generales de implementación
Para llevar a cabo la implementación se utilizaron las siguientes herramientas:
Para la el desarrollo de la aplicación se utilizará Java J2SE Development Kit en su
versión 1.6.0, soportado sobre Microsoft Windows. Esta versión proporciona un
compilador y un conjunto de herramientas para crear programas independientes y
java applets.
Capítulo 5. Implementación
Página 72
Para la creación de la ontología del dominio de educación se utilizó el editor de
ontologías Protégé en su versión 3.4 Beta.
La explotación de la ontología para la herramienta fue llevada a cabo por medio de la
API Jena en su versión 2.5.5.
5.2.2. Implementación de módulos
Los detalles mostrados a continuación se refieren a cada módulo implementado de la herramienta de software EDWEB.
Los módulos implementados tienen su equivalente con un caso de uso de la fase de análisis.
5.2.2.1. Carga de la ontología La figura 5.3 muestra las clases necesarias para obtener acceso a la ontología del dominio de educación creada con la herramienta Protégé. Para ello se importa la API Jena, que permite la explotación de datos de la ontología en formato OWL. Las librerías Individual, OntClass y Resource, ayudan a manejo de nodos, descripciones de clases y manejo de recursos RDF.
La clase JenaParser se utiliza para mostrar las clases, instancias y las clases inferidas
con el modelo de inferencia. Las clases e instancias obtenidas de la ontología en OWL se listan en una instancia de
la clase JTree, aunque se listan únicamente las hojas de la ontología pues son éstas las utilizadas en la creación de grafos.
Capítulo 5. Implementación
Página 73
Figura 5.3. Clases para explotación de la ontología
5.2.2.2. Creación de grafos con la herramienta Este módulo es equivalente al CU-1 Crear grafo del sitio Web. Para la creación de un nuevo grafo con el editor de sitios Web se usan las clases Node y LBNode con el argumento que corresponde al nombre del nodo principal por defecto.
Esta acción creará un nuevo panel de trabajo con un nodo inicial llamado “UnidadOrganizacional:Principal”.
Un grafo se conforma de un número de nodos, tomados de la lista de clases de la
ontología, y aristas proporcionadas por el usuario. Los nodos poseen propiedades por defecto como nombre, tipo de clase a la que pertenece e incluso un campo descriptivo.
Las aristas se crean por medio de las clases Edge y LBEdge. Requieren como
parámetros de entrada, un nodo origen, un nodo destino y una longitud de arista. Este último valor es tomado de los datos por defecto.
Al completar una tripleta existe un proceso de validación de la misma, asegurándose
de que dichos nodos pueden enlazarse por medio de la relación seleccionada. La clase Validator contiene el método validate, encargado de la verificación de la tripleta generada. Para realizar la validación se envían los datos de la tripleta (objetos LBNode y LBEdge) a la clase Validator desde el método mouseReleased de la clase LBDragAddNodeUI.
class client
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
JenaParser
- fi le: File = null
- model: OntModel = null
+ getIndividuals() : List<Individual>
+ getInfModel() : InfModel
+ getOntClass() : List<OntClass>
+ JenaParser(File)
-parser
Capítulo 5. Implementación
Página 74
Finalmente, al crear la tripleta se despliega una ventana de edición del nodo donde el usuario puede modificar las características del nodo destino. Para ello, la clase LBNodeDialog cuenta con el método saveChangesAndHideDialog.
Figura 5.4. Diagrama de actividades para la creación de grafos
La figura 5.4 muestra el diagrama de las actividades llevadas a cabo para crear un
grafo de sitio nuevo. Las clases que intervienen en esta tarea pueden observarse en la figura 5.5.
Capítulo 5. Implementación
Página 75
class client
Edge
# col: Color
+ DEFAULT_COLOR: Color = Color.decode("#...
+ DEFAULT_LENGTH: int = 350
+ from: Node
# length: int
+ MOUSE_OVER_COLOR: Color
+ to: Node
# visible: boolean
+ containsPoint(double, double) : boolean
+ distFromPoint(double, double) : double
+ Edge(Node, Node, int)
+ Edge(Node, Node)
+ getColor() : Color
+ getFrom() : Node
+ getLength() : int
+ getOtherEndpt(Node) : Node
+ getTo() : Node
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ paint(Graphics, TGPanel) : void
+ paintArrow(Graphics, int, int, int, int, Color) : void
+ reverse() : void
+ setColor(Color) : void
+ setEdgeDefaultColor(Color) : void
+ setEdgeDefaultLength(int) : void
+ setEdgeMouseOverColor(Color) : void
+ setLength(int) : void
+ setVisible(boolean) : void
GraphEltSet
# edges: Vector
+ nodeCount: int
# nodeIDRegistry: Hashtable = null
# nodes: Vector
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addNode(Node) : void
+ calculateDistances(Node, int) : Hashtable
+ clearAll() : void
+ contains(Node) : boolean
+ contains(Edge) : boolean
+ deleteEdge(Edge) : boolean
+ deleteEdge(Node, Node) : boolean
+ deleteEdges(Vector) : void
+ deleteNode(Node) : boolean
+ deleteNodes(Vector) : void
# edgeAt(int) : Edge
+ edgeNum() : int
+ findEdge(Node, Node) : Edge
+ findNode(String) : Node
+ findNodesByLabel(String) : Collection
+ forAllEdges(TGForEachEdge) : void
+ forAllNodePairs(TGForEachNodePair) : void
+ forAllNodes(TGForEachNode) : void
+ getFirstNode() : Node
+ getRandomNode() : Node
+ GraphEltSet()
# nodeAt(int) : Node
+ nodeNum() : int
TGAbstractDragUI
LBDragAddNodeUI
~ cboParRel: JComboBox
~ dragAddNode: LBNode
~ mousePos: Point
~ newNode: String = "UnidadOrganiza...
~ result: Boolean
~ tgLinkBrowser: TGLinkBrowser
+ LBDragAddNodeUI(TGLinkBrowser)
+ mouseDragged(MouseEvent) : void
+ mousePressed(MouseEvent) : void
+ mouseReleased(MouseEvent) : void
+ paintAfterEdges(Graphics) : void
+ paintFirst(Graphics) : void
+ paintLast(Graphics) : void
+ preActivate() : void
+ preDeactivate() : void
+ returnData() : String
LBEdge
+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}
+ DEFAULT_TYPE: int = 1
+ edgeType: int
+ HIERARCHICAL_EDGE: int = 1 {readOnly}
- label: String
+ LABEL_BACK_COLOR: Color = new Color(255, ...
+ LABEL_FONT: Font = new Font("Couri...
+ LABEL_TEXT_COLOR: Color
+ getLabel() : String
+ getType() : int
+ LBEdge(LBNode, LBNode)
+ LBEdge(LBNode, LBNode, int)
+ paint(Graphics, int, int, int, int, Color, int) : void
+ paint(Graphics, TGPanel) : void
+ paintEdgeBody(Graphics, TGPanel) : void
+ paintFatLine(Graphics, int, int, int, int, Color) : void
+ setEdgeDafaultType(int) : void
+ setLabel(String) : void
+ setType(int) : void
LBNode
~ hint: String
+ HINT_BACK_COLOR: Color
+ HINT_FONT: Font = new Font("Couri...
+ HINT_TEXT_COLOR: Color
~ hintFont: Font
~ hintHeight: int
~ hintIsHTML: boolean
~ hintWidth: int
+ MINIMUM_HINT_HEIGHT: int = 20
~ url: String
~ urlIsLocal: boolean
~ urlIsXML: boolean
+ getHeight() : int
+ getHint() : String
+ getHintHeight() : int
+ getHintIsHTML() : boolean
+ getHintWidth() : int
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getPaintUnselectedBackColor() : Color
+ getURL() : String
+ getURLIsLocal() : boolean
+ getURLIsXML() : boolean
+ getWidth() : int
+ LBNode()
+ LBNode(String)
+ LBNode(String, String, String)
~ myBrighter(Color) : Color
+ paint(Graphics, TGPanel) : void
+ separatorString(String) : String
+ setHint(String) : void
+ setHintHeight(int) : void
+ setHintIsHTML(boolean) : void
+ setHintWidth(int) : void
+ setNodeHintBackColor(Color) : void
+ setNodeHintFont(Font) : void
+ setNodeHintTextColor(Color) : void
+ setURL(String) : void
+ setURLIsLocal(boolean) : void
+ setURLIsXML(boolean) : void
JInternalFrame
LBNodeDialog
- cbHintIsHTML: JCheckBox
- cbLocal: JCheckBox
- cboFontSize: JComboBox
- cboNodeType: JComboBox
- cbXML: JCheckBox
- cmdCancel: JButton
- cmdOK: JButton
- lastBackColorButton: JButton
- lastTextColorButton: JButton
- lblBackColor: JLabel
- lblTextColor: JLabel
~ lbNode: LBNode
- taHint: JTextArea
- tfBackColor: JTextField
- tfHintHeight: JTextField
- tfHintWidth: JTextField
- tfLabel: JTextField
- tfTextColor: JTextField
- tfURL: JTextField
~ tgPanel: TGPanel
- encodeColor(Color) : String
- initColorSelectors() : void
- initComponents() : void
+ LBNodeDialog(TGPanel)
+ main(String[]) : void
+ saveChangesAndHideDialog() : void
- setBackColor(Color) : void
+ setLBNode(LBNode) : void
- setTextColor(Color) : void
+ showDialog() : void
Node
+ AUTO_ID_STRING: String = "AutoID " {readOnly}
+ BACK_DEFAULT_COLOR: Color = new Color(208, ...
+ BACK_FIXED_COLOR: Color
+ BACK_HILIGHT_COLOR: Color = Color.decode("#...
+ BACK_SELECT_COLOR: Color = new Color(255, ...
# backColor: Color
+ BORDER_DRAG_COLOR: Color
+ BORDER_INACTIVE_COLOR: Color
+ BORDER_MOUSE_OVER_COLOR: Color = new Color(160, ...
+ DEFAULT_TYPE: int = 1
+ drawx: double
+ drawy: double
# dx: double
# dy: double
- edges: Vector
# fixed: boolean
# font: Font
# fontMetrics: FontMetrics
- id: String
+ justMadeLocal: boolean
# lbl: String
+ localEdgeCount: int
+ markedForRemoval: boolean
# nm: String
# repulsion: int
+ SMALL_TAG_FONT: Font = new Font("Couri... {readOnly}
+ TEXT_COLOR: Color
+ TEXT_FONT: Font = new Font("Couri...
# textColor: Color
# typ: int
+ TYPE_ELLIPSE: int = 3 {readOnly}
+ TYPE_RECTANGLE: int = 1 {readOnly}
+ TYPE_ROUNDRECT: int = 2 {readOnly}
# visible: boolean
+ x: double
+ y: double
+ addEdge(Edge) : void
+ containsPoint(double, double) : boolean
+ containsPoint(Point) : boolean
+ edgeAt(int) : Edge
+ edgeNum() : int
+ getBackColor() : Color
+ getFixed() : boolean
+ getFont() : Font
+ getHeight() : int
+ getID() : String
+ getLabel() : String
+ getLocation() : Point
+ getName() : String
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getTextColor() : Color
+ getType() : int
+ getWidth() : int
- initialize(String) : void
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ localEdgeNum() : int
+ Node()
+ Node(String)
+ Node(String, String)
+ Node(String, int, Color, String)
+ paint(Graphics, TGPanel) : void
+ paintNodeBody(Graphics, TGPanel) : void
+ paintSmallTag(Graphics, TGPanel, int, int, Color, Color, char) : void
+ removeEdge(Edge) : void
+ setBackColor(Color) : void
+ setFixed(boolean) : void
+ setFont(Font) : void
+ setID(String) : void
+ setLabel(String) : void
+ setLocation(Point) : void
+ setName(String) : void
+ setNodeBackDefaultColor(Color) : void
+ setNodeBackFixedColor(Color) : void
+ setNodeBackHilightColor(Color) : void
+ setNodeBackSelectColor(Color) : void
+ setNodeBorderDragColor(Color) : void
+ setNodeBorderInactiveColor(Color) : void
+ setNodeBorderMouseOverColor(Color) : void
+ setNodeTextColor(Color) : void
+ setNodeTextFont(Font) : void
+ setNodeType(int) : void
+ setTextColor(Color) : void
+ setType(int) : void
+ setVisible(boolean) : void
Runnable
TGLayout
- damper: double
- damping: boolean
~ dragNode: Node
- lastMaxMotion: double
- maxMotion: double
- motionRatio: double
- newRigidity: double
- relaxer: Thread
- rigidity: double
- tgPanel: TGPanel
- avoidLabels() : void
+ damp() : void
- moveNodes() : void
- myWait() : void
- relax() : void
- relaxEdges() : void
+ resetDamper() : void
+ run() : void
~ setDragNode(Node) : void
~ setRigidity(double) : void
+ start() : void
+ startDamper() : void
+ stop() : void
+ stopDamper() : void
+ TGLayout(TGPanel)
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
JPanel
TGPanel
~ adjustOriginLens: AdjustOriginLens
+ BACK_COLOR: Color = Color.white
# basicMML: BasicMouseMotionListener
~ bottomRightDraw: TGPoint2D = null
- completeEltSet: GraphEltSet
~ dragNode: Node
- graphListeners: Vector
- localityUtils: LocalityUtils
# maintainMouseOver: boolean = false
# mouseOverE: Edge
# mouseOverN: Node
# mousePos: Point
- nombreNodo: String
~ offgraphics: Graphics
~ offscreen: Image
~ offscreensize: Dimension
- paintListeners: Vector
# select: Node
~ switchSelectUI: SwitchSelectUI
+ tgLayout: TGLayout
~ tgLensSet: TGLensSet
~ topLeftDraw: TGPoint2D = null
- visibleLocality: VisibleLocality
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addGraphListener(GraphListener) : void
+ addNode() : Node
+ addNode(String) : Node
+ addNode(String, String) : Node
+ addNode(Node) : void
+ addPaintListener(TGPaintListener) : void
+ clearAll() : void
+ clearSelect() : void
+ deleteEdge(Edge) : void
+ deleteEdge(Node, Node) : void
+ deleteNode(Node) : boolean
+ deleteNodeById(String) : boolean
+ edgeNum() : int
+ expandNode(Node) : void
+ findEdge(Node, Node) : Edge
# findMouseOver() : void
+ findNode(String) : Node
~ fireMovedEvent() : void
+ fireResetEvent() : void
+ getAdjustOriginLens() : AdjustOriginLens
+ getBottomRightDraw() : TGPoint2D
+ getCenter() : TGPoint2D
+ getDragNode() : Node
+ getDrawCenter() : TGPoint2D
+ getGES() : InmutableGraphEltSet
+ getMouseOverE() : Edge
+ getMouseOverN() : Node
+ getMousePos() : Point
+ getNodeCount() : int
+ getNombreNodo(String) : String
+ getSelect() : Node
+ getSwitchSelectUI() : SwitchSelectUI
+ getTopLeftDraw() : TGPoint2D
+ hideEdge(Edge) : void
+ hideNode(Node, Node) : void
+ main(String[]) : void
+ multiSelect(TGPoint2D, TGPoint2D) : void
~ myBrihgter(Color) : Color
+ nodeNum() : int
+ paint(Graphics) : void
+ processGraphMove() : void
- redraw() : void
+ removeGraphListener(GraphListener) : void
+ removePaintListener(TGPaintListener) : void
+ repaintAfterMove() : void
+ resetDamper() : void
+ selectFirstNode() : void
+ setBackColor(Color) : void
+ setDragNode(Node) : void
+ setGraphEltSet(GraphEltSet) : void
+ setLensSet(TGLensSet) : void
+ setLocale(Node, int) : void
+ setMaintainMouseOver(boolean) : void
+ setMouseOverE(Edge) : void
+ setMouseOverN(Node) : void
~ setMousePos(Point) : void
+ setNombreNodo(String) : void
+ setSelect(Node) : void
+ setTGLayout(TGLayout) : void
+ startDamper() : void
+ stopDamper() : void
+ TGPanel()
+ update(Graphics) : void
+ updateDrawPos(Node) : void
+ updateDrawPositions() : void
+ updateGraphSize() : void
+ updateLocalityFromVisibil ity() : void
+ updatePosFromDraw(Node) : void
~tgLinkBrowser
~lbNode
+from
+to
+tgLayout
#select
#mouseOverN
#mouseOverE
~tgPanel
#lbNodeDialog
~tgPanel
~dragNode
-completeEltSet
~completeEltSet
-tgPanel
~dragNode
~dragAddNode
Figura 5.5. Clases para la creación de grafos
Capítulo 5. Implementación
Página 76
5.2.2.3. Crear archivo XML a partir de un grafo
El módulo descrito es equivalente al CU-2 Crear archivo XML a partir de un grafo .Al momento de almacenar el archivo XML se llama a la clase XMLio que contiene un conjunto de métodos que permiten la lectura y escritura de nodos y aristas en un archivo que toma como base una DTD.
El archivo de la DTD se divide en dos secciones:
NODESET: contiene los datos del nodo como identificador, etiqueta, localización,
color, fuente y tipo de clase a la que pertenece.
EDGESET: contiene los datos de la arista como la etiqueta, color, nodo origen, nodo
destino y longitud.
Para la creación del XML (figura 5.6) se utiliza un buffer que guarda línea por línea el contenido de la DTD TG_Prepend_DTD.xml y el contenido del grafo, agrupando cada elemento en su sección correspondiente.
La creación del archivo inicia con la clase TGLinkBrowser (figura 5.7), desde la cual el
usuario solicita guardar el archivo XML del grafo creado en el panel. TGLinkBrowser llama al método write de la clase XMLio con el parámetro saveFileStream que contiene la ruta en la que se almacenará el archivo XML.
XMLio crea el archivo XML y copia en los bloques NODESET y EDGESET los datos de
los nodos y aristas.
Figura 5.6. Diagrama de actividades para la creación de un archivo XML
Capítulo 5. Implementación
Página 77
class client
Edge
# col: Color
+ DEFAULT_COLOR: Color = Color.decode("#...
+ DEFAULT_LENGTH: int = 350
+ from: Node
# length: int
+ MOUSE_OVER_COLOR: Color
+ to: Node
# visible: boolean
+ containsPoint(double, double) : boolean
+ distFromPoint(double, double) : double
+ Edge(Node, Node, int)
+ Edge(Node, Node)
+ getColor() : Color
+ getFrom() : Node
+ getLength() : int
+ getOtherEndpt(Node) : Node
+ getTo() : Node
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ paint(Graphics, TGPanel) : void
+ paintArrow(Graphics, int, int, int, int, Color) : void
+ reverse() : void
+ setColor(Color) : void
+ setEdgeDefaultColor(Color) : void
+ setEdgeDefaultLength(int) : void
+ setEdgeMouseOverColor(Color) : void
+ setLength(int) : void
+ setVisible(boolean) : void
GraphEltSet
# edges: Vector
+ nodeCount: int
# nodeIDRegistry: Hashtable = null
# nodes: Vector
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addNode(Node) : void
+ calculateDistances(Node, int) : Hashtable
+ clearAll() : void
+ contains(Node) : boolean
+ contains(Edge) : boolean
+ deleteEdge(Edge) : boolean
+ deleteEdge(Node, Node) : boolean
+ deleteEdges(Vector) : void
+ deleteNode(Node) : boolean
+ deleteNodes(Vector) : void
# edgeAt(int) : Edge
+ edgeNum() : int
+ findEdge(Node, Node) : Edge
+ findNode(String) : Node
+ findNodesByLabel(String) : Collection
+ forAllEdges(TGForEachEdge) : void
+ forAllNodePairs(TGForEachNodePair) : void
+ forAllNodes(TGForEachNode) : void
+ getFirstNode() : Node
+ getRandomNode() : Node
+ GraphEltSet()
# nodeAt(int) : Node
+ nodeNum() : int
LBEdge
+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}
+ DEFAULT_TYPE: int = 1
+ edgeType: int
+ HIERARCHICAL_EDGE: int = 1 {readOnly}
- label: String
+ LABEL_BACK_COLOR: Color = new Color(255, ...
+ LABEL_FONT: Font = new Font("Couri...
+ LABEL_TEXT_COLOR: Color
+ getLabel() : String
+ getType() : int
+ LBEdge(LBNode, LBNode)
+ LBEdge(LBNode, LBNode, int)
+ paint(Graphics, int, int, int, int, Color, int) : void
+ paint(Graphics, TGPanel) : void
+ paintEdgeBody(Graphics, TGPanel) : void
+ paintFatLine(Graphics, int, int, int, int, Color) : void
+ setEdgeDafaultType(int) : void
+ setLabel(String) : void
+ setType(int) : void
LBNode
~ hint: String
+ HINT_BACK_COLOR: Color
+ HINT_FONT: Font = new Font("Couri...
+ HINT_TEXT_COLOR: Color
~ hintFont: Font
~ hintHeight: int
~ hintIsHTML: boolean
~ hintWidth: int
+ MINIMUM_HINT_HEIGHT: int = 20
~ url: String
~ urlIsLocal: boolean
~ urlIsXML: boolean
+ getHeight() : int
+ getHint() : String
+ getHintHeight() : int
+ getHintIsHTML() : boolean
+ getHintWidth() : int
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getPaintUnselectedBackColor() : Color
+ getURL() : String
+ getURLIsLocal() : boolean
+ getURLIsXML() : boolean
+ getWidth() : int
+ LBNode()
+ LBNode(String)
+ LBNode(String, String, String)
~ myBrighter(Color) : Color
+ paint(Graphics, TGPanel) : void
+ separatorString(String) : String
+ setHint(String) : void
+ setHintHeight(int) : void
+ setHintIsHTML(boolean) : void
+ setHintWidth(int) : void
+ setNodeHintBackColor(Color) : void
+ setNodeHintFont(Font) : void
+ setNodeHintTextColor(Color) : void
+ setURL(String) : void
+ setURLIsLocal(boolean) : void
+ setURLIsXML(boolean) : void
Node
+ AUTO_ID_STRING: String = "AutoID " {readOnly}
+ BACK_DEFAULT_COLOR: Color = new Color(208, ...
+ BACK_FIXED_COLOR: Color
+ BACK_HILIGHT_COLOR: Color = Color.decode("#...
+ BACK_SELECT_COLOR: Color = new Color(255, ...
# backColor: Color
+ BORDER_DRAG_COLOR: Color
+ BORDER_INACTIVE_COLOR: Color
+ BORDER_MOUSE_OVER_COLOR: Color = new Color(160, ...
+ DEFAULT_TYPE: int = 1
+ drawx: double
+ drawy: double
# dx: double
# dy: double
- edges: Vector
# fixed: boolean
# font: Font
# fontMetrics: FontMetrics
- id: String
+ justMadeLocal: boolean
# lbl: String
+ localEdgeCount: int
+ markedForRemoval: boolean
# nm: String
# repulsion: int
+ SMALL_TAG_FONT: Font = new Font("Couri... {readOnly}
+ TEXT_COLOR: Color
+ TEXT_FONT: Font = new Font("Couri...
# textColor: Color
# typ: int
+ TYPE_ELLIPSE: int = 3 {readOnly}
+ TYPE_RECTANGLE: int = 1 {readOnly}
+ TYPE_ROUNDRECT: int = 2 {readOnly}
# visible: boolean
+ x: double
+ y: double
+ addEdge(Edge) : void
+ containsPoint(double, double) : boolean
+ containsPoint(Point) : boolean
+ edgeAt(int) : Edge
+ edgeNum() : int
+ getBackColor() : Color
+ getFixed() : boolean
+ getFont() : Font
+ getHeight() : int
+ getID() : String
+ getLabel() : String
+ getLocation() : Point
+ getName() : String
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getTextColor() : Color
+ getType() : int
+ getWidth() : int
- initialize(String) : void
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ localEdgeNum() : int
+ Node()
+ Node(String)
+ Node(String, String)
+ Node(String, int, Color, String)
+ paint(Graphics, TGPanel) : void
+ paintNodeBody(Graphics, TGPanel) : void
+ paintSmallTag(Graphics, TGPanel, int, int, Color, Color, char) : void
+ removeEdge(Edge) : void
+ setBackColor(Color) : void
+ setFixed(boolean) : void
+ setFont(Font) : void
+ setID(String) : void
+ setLabel(String) : void
+ setLocation(Point) : void
+ setName(String) : void
+ setNodeBackDefaultColor(Color) : void
+ setNodeBackFixedColor(Color) : void
+ setNodeBackHilightColor(Color) : void
+ setNodeBackSelectColor(Color) : void
+ setNodeBorderDragColor(Color) : void
+ setNodeBorderInactiveColor(Color) : void
+ setNodeBorderMouseOverColor(Color) : void
+ setNodeTextColor(Color) : void
+ setNodeTextFont(Font) : void
+ setNodeType(int) : void
+ setTextColor(Color) : void
+ setType(int) : void
+ setVisible(boolean) : void
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
JPanel
TGPanel
~ adjustOriginLens: AdjustOriginLens
+ BACK_COLOR: Color = Color.white
# basicMML: BasicMouseMotionListener
~ bottomRightDraw: TGPoint2D = null
- completeEltSet: GraphEltSet
~ dragNode: Node
- graphListeners: Vector
- localityUtils: LocalityUtils
# maintainMouseOver: boolean = false
# mouseOverE: Edge
# mouseOverN: Node
# mousePos: Point
- nombreNodo: String
~ offgraphics: Graphics
~ offscreen: Image
~ offscreensize: Dimension
- paintListeners: Vector
# select: Node
~ switchSelectUI: SwitchSelectUI
+ tgLayout: TGLayout
~ tgLensSet: TGLensSet
~ topLeftDraw: TGPoint2D = null
- visibleLocality: VisibleLocality
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addGraphListener(GraphListener) : void
+ addNode() : Node
+ addNode(String) : Node
+ addNode(String, String) : Node
+ addNode(Node) : void
+ addPaintListener(TGPaintListener) : void
+ clearAll() : void
+ clearSelect() : void
+ deleteEdge(Edge) : void
+ deleteEdge(Node, Node) : void
+ deleteNode(Node) : boolean
+ deleteNodeById(String) : boolean
+ edgeNum() : int
+ expandNode(Node) : void
+ findEdge(Node, Node) : Edge
# findMouseOver() : void
+ findNode(String) : Node
~ fireMovedEvent() : void
+ fireResetEvent() : void
+ getAdjustOriginLens() : AdjustOriginLens
+ getBottomRightDraw() : TGPoint2D
+ getCenter() : TGPoint2D
+ getDragNode() : Node
+ getDrawCenter() : TGPoint2D
+ getGES() : InmutableGraphEltSet
+ getMouseOverE() : Edge
+ getMouseOverN() : Node
+ getMousePos() : Point
+ getNodeCount() : int
+ getNombreNodo(String) : String
+ getSelect() : Node
+ getSwitchSelectUI() : SwitchSelectUI
+ getTopLeftDraw() : TGPoint2D
+ hideEdge(Edge) : void
+ hideNode(Node, Node) : void
+ main(String[]) : void
+ multiSelect(TGPoint2D, TGPoint2D) : void
~ myBrihgter(Color) : Color
+ nodeNum() : int
+ paint(Graphics) : void
+ processGraphMove() : void
- redraw() : void
+ removeGraphListener(GraphListener) : void
+ removePaintListener(TGPaintListener) : void
+ repaintAfterMove() : void
+ resetDamper() : void
+ selectFirstNode() : void
+ setBackColor(Color) : void
+ setDragNode(Node) : void
+ setGraphEltSet(GraphEltSet) : void
+ setLensSet(TGLensSet) : void
+ setLocale(Node, int) : void
+ setMaintainMouseOver(boolean) : void
+ setMouseOverE(Edge) : void
+ setMouseOverN(Node) : void
~ setMousePos(Point) : void
+ setNombreNodo(String) : void
+ setSelect(Node) : void
+ setTGLayout(TGLayout) : void
+ startDamper() : void
+ stopDamper() : void
+ TGPanel()
+ update(Graphics) : void
+ updateDrawPos(Node) : void
+ updateDrawPositions() : void
+ updateGraphSize() : void
+ updateLocalityFromVisibil ity() : void
+ updatePosFromDraw(Node) : void
XMLio
~ graphEltSet: GraphEltSet
~ parameterHash: Hashtable
- buildGraphEltSet(IXMLElement, Thread) : void
- encodeColor(Color) : String
- getBooleanAttr(IXMLElement, String, boolean) : boolean
+ getClassName() : String
+ getLocalDirName() : String
+ getParameterHash() : Hashtable
+ read(String) : void
+ read(URL) : void
+ read(String, Thread) : void
+ read(URL, Thread) : void
+ read(String, InputStream, Thread) : void
+ setParameterHash(Hashtable) : void
+ write(OutputStream) : void
~ XMLio(GraphEltSet)
+from
+to
#select
#mouseOverN
#mouseOverE
~xmlio
~tgPanel
~graphEltSet
-completeEltSet
~completeEltSet
~dragNode
Figura 5.7. Diagrama de clases para la creación de un archivo XML
Capítulo 5. Implementación
Página 78
5.2.2.4. Generar grafo a partir de un archivo XML Este módulo es equivalente al CU-3 Generar grafo a partir de un archivo XML. Al generar un grafo a partir de un archivo XML existente, la clase TGLinkBrowser manda al método read de la clase XMLio el parámetro la ruta del archivo almacenada en la variable loadFile. Posteriormente se extrae de la ruta el nombre del archivo.
XMLio verifica el tipo de archivo de entrada y llama al método buildGraphEltSet.
Figura 5.8. Diagrama de clases para la generación de un grafo
a partir de un archivo XML
Las clases que intervienen en esa tarea se muestran en la figura 5.8 y las actividades necesarias para llevarla a cabo se observan en la figura 5.9.
class client
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
XMLio
~ graphEltSet: GraphEltSet
~ parameterHash: Hashtable
- buildGraphEltSet(IXMLElement, Thread) : void
- encodeColor(Color) : String
- getBooleanAttr(IXMLElement, String, boolean) : boolean
+ getClassName() : String
+ getLocalDirName() : String
+ getParameterHash() : Hashtable
+ read(String) : void
+ read(URL) : void
+ read(String, Thread) : void
+ read(URL, Thread) : void
+ read(String, InputStream, Thread) : void
+ setParameterHash(Hashtable) : void
+ write(OutputStream) : void
~ XMLio(GraphEltSet)
~xmlio
Capítulo 5. Implementación
Página 79
Figura 5.9. Diagrama de actividades para la generación de un grafo
a partir de un archivo XML
5.2.2.5. Generar estructura del sitio Web
El módulo descrito tiene su equivalente en el CU-4 Generar estructura del sitio Web. Una estructura de sitio Web se compone de un conjunto de páginas en blanco que se encuentran etiquetadas en el archivo XML correspondiente. Cada página contiene los enlaces que la relacionan con otras páginas dentro del sitio Web.
Para la generación de la estructura se ha implementado la clase ParserHTML que contiene métodos para la lectura de archivos XML y la creación de elemento HTML.
La clase ParserHTML contiene al método buildPages que se encarga de la creación del
directorio. Para esto es necesario obtener el nombre del archivo XML con el que se está trabajando. El nombre se almacena en la variable Global.openedFile, que es una variable de tipo Global proveniente de la clase TGLinkBrowser.
Se crea una carpeta con el nombre contenido en dicha variable y en ella se almacenan
las páginas del sitio. Esta tarea implica el recorrido del archivo XML que se hace con elementos de la clase IXMLElement.
Los elementos IXMLElement permiten el acceso a los elementos contenidos en el archivo XML por separado, es decir a las secciones NODESET y EDGESET, de modo que puedan usarse individualmente.
Dentro de buildPages se realizan tres ciclos: el primer ciclo se encarga de dar lectura a
cada nodo almacenado en el archivo XML, dentro de la sección NODESET. Para cada nodo encontrado se crean las cabeceras de la página HTML correspondiente. Un segundo ciclo ayuda a encontrar el nombre de las aristas asociadas al identificador de cada nodo en la
Capítulo 5. Implementación
Página 80
sección EDGESET. Por último, el tercer ciclo se encarga de recorrer nuevamente la sección EDGESET para encontrar los nodos destinos con los que cada nodo se relaciona.
Figura 5.10. Diagrama de actividades para la generación de estructuras de sitios Web
De esta manera se insertan los enlaces en cada página (figura 5.10). El diagrama de clases de esta tarea se muestra en la figura 5.11.
Capítulo 5. Implementación
Página 81
class client
TGForEachNode
+ forEachNode(Node) : void
+ TGForEachNode()
TGForEachEdge
+ forEachEdge(Edge) : void
+ TGForEachEdge()
Edge
# col: Color
+ DEFAULT_COLOR: Color = Color.decode("#...
+ DEFAULT_LENGTH: int = 350
+ from: Node
# length: int
+ MOUSE_OVER_COLOR: Color
+ to: Node
# visible: boolean
+ containsPoint(double, double) : boolean
+ distFromPoint(double, double) : double
+ Edge(Node, Node, int)
+ Edge(Node, Node)
+ getColor() : Color
+ getFrom() : Node
+ getLength() : int
+ getOtherEndpt(Node) : Node
+ getTo() : Node
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ paint(Graphics, TGPanel) : void
+ paintArrow(Graphics, int, int, int, int, Color) : void
+ reverse() : void
+ setColor(Color) : void
+ setEdgeDefaultColor(Color) : void
+ setEdgeDefaultLength(int) : void
+ setEdgeMouseOverColor(Color) : void
+ setLength(int) : void
+ setVisible(boolean) : void
GraphEltSet
# edges: Vector
+ nodeCount: int
# nodeIDRegistry: Hashtable = null
# nodes: Vector
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addNode(Node) : void
+ calculateDistances(Node, int) : Hashtable
+ clearAll() : void
+ contains(Node) : boolean
+ contains(Edge) : boolean
+ deleteEdge(Edge) : boolean
+ deleteEdge(Node, Node) : boolean
+ deleteEdges(Vector) : void
+ deleteNode(Node) : boolean
+ deleteNodes(Vector) : void
# edgeAt(int) : Edge
+ edgeNum() : int
+ findEdge(Node, Node) : Edge
+ findNode(String) : Node
+ findNodesByLabel(String) : Collection
+ forAllEdges(TGForEachEdge) : void
+ forAllNodePairs(TGForEachNodePair) : void
+ forAllNodes(TGForEachNode) : void
+ getFirstNode() : Node
+ getRandomNode() : Node
+ GraphEltSet()
# nodeAt(int) : Node
+ nodeNum() : int
LBEdge
+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}
+ DEFAULT_TYPE: int = 1
+ edgeType: int
+ HIERARCHICAL_EDGE: int = 1 {readOnly}
- label: String
+ LABEL_BACK_COLOR: Color = new Color(255, ...
+ LABEL_FONT: Font = new Font("Couri...
+ LABEL_TEXT_COLOR: Color
+ getLabel() : String
+ getType() : int
+ LBEdge(LBNode, LBNode)
+ LBEdge(LBNode, LBNode, int)
+ paint(Graphics, int, int, int, int, Color, int) : void
+ paint(Graphics, TGPanel) : void
+ paintEdgeBody(Graphics, TGPanel) : void
+ paintFatLine(Graphics, int, int, int, int, Color) : void
+ setEdgeDafaultType(int) : void
+ setLabel(String) : void
+ setType(int) : void
JInternalFrame
LBNodeDialog
- cbHintIsHTML: JCheckBox
- cbLocal: JCheckBox
- cboFontSize: JComboBox
- cboNodeType: JComboBox
- cbXML: JCheckBox
- cmdCancel: JButton
- cmdOK: JButton
- lastBackColorButton: JButton
- lastTextColorButton: JButton
- lblBackColor: JLabel
- lblTextColor: JLabel
~ lbNode: LBNode
- taHint: JTextArea
- tfBackColor: JTextField
- tfHintHeight: JTextField
- tfHintWidth: JTextField
- tfLabel: JTextField
- tfTextColor: JTextField
- tfURL: JTextField
~ tgPanel: TGPanel
- encodeColor(Color) : String
- initColorSelectors() : void
- initComponents() : void
+ LBNodeDialog(TGPanel)
+ main(String[]) : void
+ saveChangesAndHideDialog() : void
- setBackColor(Color) : void
+ setLBNode(LBNode) : void
- setTextColor(Color) : void
+ showDialog() : void
LBNode
~ hint: String
+ HINT_BACK_COLOR: Color
+ HINT_FONT: Font = new Font("Couri...
+ HINT_TEXT_COLOR: Color
~ hintFont: Font
~ hintHeight: int
~ hintIsHTML: boolean
~ hintWidth: int
+ MINIMUM_HINT_HEIGHT: int = 20
~ url: String
~ urlIsLocal: boolean
~ urlIsXML: boolean
+ getHeight() : int
+ getHint() : String
+ getHintHeight() : int
+ getHintIsHTML() : boolean
+ getHintWidth() : int
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getPaintUnselectedBackColor() : Color
+ getURL() : String
+ getURLIsLocal() : boolean
+ getURLIsXML() : boolean
+ getWidth() : int
+ LBNode()
+ LBNode(String)
+ LBNode(String, String, String)
~ myBrighter(Color) : Color
+ paint(Graphics, TGPanel) : void
+ separatorString(String) : String
+ setHint(String) : void
+ setHintHeight(int) : void
+ setHintIsHTML(boolean) : void
+ setHintWidth(int) : void
+ setNodeHintBackColor(Color) : void
+ setNodeHintFont(Font) : void
+ setNodeHintTextColor(Color) : void
+ setURL(String) : void
+ setURLIsLocal(boolean) : void
+ setURLIsXML(boolean) : void
Node
+ AUTO_ID_STRING: String = "AutoID " {readOnly}
+ BACK_DEFAULT_COLOR: Color = new Color(208, ...
+ BACK_FIXED_COLOR: Color
+ BACK_HILIGHT_COLOR: Color = Color.decode("#...
+ BACK_SELECT_COLOR: Color = new Color(255, ...
# backColor: Color
+ BORDER_DRAG_COLOR: Color
+ BORDER_INACTIVE_COLOR: Color
+ BORDER_MOUSE_OVER_COLOR: Color = new Color(160, ...
+ DEFAULT_TYPE: int = 1
+ drawx: double
+ drawy: double
# dx: double
# dy: double
- edges: Vector
# fixed: boolean
# font: Font
# fontMetrics: FontMetrics
- id: String
+ justMadeLocal: boolean
# lbl: String
+ localEdgeCount: int
+ markedForRemoval: boolean
# nm: String
# repulsion: int
+ SMALL_TAG_FONT: Font = new Font("Couri... {readOnly}
+ TEXT_COLOR: Color
+ TEXT_FONT: Font = new Font("Couri...
# textColor: Color
# typ: int
+ TYPE_ELLIPSE: int = 3 {readOnly}
+ TYPE_RECTANGLE: int = 1 {readOnly}
+ TYPE_ROUNDRECT: int = 2 {readOnly}
# visible: boolean
+ x: double
+ y: double
+ addEdge(Edge) : void
+ containsPoint(double, double) : boolean
+ containsPoint(Point) : boolean
+ edgeAt(int) : Edge
+ edgeNum() : int
+ getBackColor() : Color
+ getFixed() : boolean
+ getFont() : Font
+ getHeight() : int
+ getID() : String
+ getLabel() : String
+ getLocation() : Point
+ getName() : String
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getTextColor() : Color
+ getType() : int
+ getWidth() : int
- initialize(String) : void
+ intersects(Dimension) : boolean
+ isVisible() : boolean
+ localEdgeNum() : int
+ Node()
+ Node(String)
+ Node(String, String)
+ Node(String, int, Color, String)
+ paint(Graphics, TGPanel) : void
+ paintNodeBody(Graphics, TGPanel) : void
+ paintSmallTag(Graphics, TGPanel, int, int, Color, Color, char) : void
+ removeEdge(Edge) : void
+ setBackColor(Color) : void
+ setFixed(boolean) : void
+ setFont(Font) : void
+ setID(String) : void
+ setLabel(String) : void
+ setLocation(Point) : void
+ setName(String) : void
+ setNodeBackDefaultColor(Color) : void
+ setNodeBackFixedColor(Color) : void
+ setNodeBackHilightColor(Color) : void
+ setNodeBackSelectColor(Color) : void
+ setNodeBorderDragColor(Color) : void
+ setNodeBorderInactiveColor(Color) : void
+ setNodeBorderMouseOverColor(Color) : void
+ setNodeTextColor(Color) : void
+ setNodeTextFont(Font) : void
+ setNodeType(int) : void
+ setTextColor(Color) : void
+ setType(int) : void
+ setVisible(boolean) : void
ParserHTML
~ graphEltSet: GraphEltSet
~ parameterHash: Hashtable
~ v: Vector
- buildPages(IXMLElement) : void
+ ParserHTML()
+ read(String, InputStream) : void
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
JPanel
TGPanel
~ adjustOriginLens: AdjustOriginLens
+ BACK_COLOR: Color = Color.white
# basicMML: BasicMouseMotionListener
~ bottomRightDraw: TGPoint2D = null
- completeEltSet: GraphEltSet
~ dragNode: Node
- graphListeners: Vector
- localityUtils: LocalityUtils
# maintainMouseOver: boolean = false
# mouseOverE: Edge
# mouseOverN: Node
# mousePos: Point
- nombreNodo: String
~ offgraphics: Graphics
~ offscreen: Image
~ offscreensize: Dimension
- paintListeners: Vector
# select: Node
~ switchSelectUI: SwitchSelectUI
+ tgLayout: TGLayout
~ tgLensSet: TGLensSet
~ topLeftDraw: TGPoint2D = null
- visibleLocality: VisibleLocality
+ addEdge(Edge) : void
+ addEdge(Node, Node, int) : Edge
+ addGraphListener(GraphListener) : void
+ addNode() : Node
+ addNode(String) : Node
+ addNode(String, String) : Node
+ addNode(Node) : void
+ addPaintListener(TGPaintListener) : void
+ clearAll() : void
+ clearSelect() : void
+ deleteEdge(Edge) : void
+ deleteEdge(Node, Node) : void
+ deleteNode(Node) : boolean
+ deleteNodeById(String) : boolean
+ edgeNum() : int
+ expandNode(Node) : void
+ findEdge(Node, Node) : Edge
# findMouseOver() : void
+ findNode(String) : Node
~ fireMovedEvent() : void
+ fireResetEvent() : void
+ getAdjustOriginLens() : AdjustOriginLens
+ getBottomRightDraw() : TGPoint2D
+ getCenter() : TGPoint2D
+ getDragNode() : Node
+ getDrawCenter() : TGPoint2D
+ getGES() : InmutableGraphEltSet
+ getMouseOverE() : Edge
+ getMouseOverN() : Node
+ getMousePos() : Point
+ getNodeCount() : int
+ getNombreNodo(String) : String
+ getSelect() : Node
+ getSwitchSelectUI() : SwitchSelectUI
+ getTopLeftDraw() : TGPoint2D
+ hideEdge(Edge) : void
+ hideNode(Node, Node) : void
+ main(String[]) : void
+ multiSelect(TGPoint2D, TGPoint2D) : void
~ myBrihgter(Color) : Color
+ nodeNum() : int
+ paint(Graphics) : void
+ processGraphMove() : void
- redraw() : void
+ removeGraphListener(GraphListener) : void
+ removePaintListener(TGPaintListener) : void
+ repaintAfterMove() : void
+ resetDamper() : void
+ selectFirstNode() : void
+ setBackColor(Color) : void
+ setDragNode(Node) : void
+ setGraphEltSet(GraphEltSet) : void
+ setLensSet(TGLensSet) : void
+ setLocale(Node, int) : void
+ setMaintainMouseOver(boolean) : void
+ setMouseOverE(Edge) : void
+ setMouseOverN(Node) : void
~ setMousePos(Point) : void
+ setNombreNodo(String) : void
+ setSelect(Node) : void
+ setTGLayout(TGLayout) : void
+ startDamper() : void
+ stopDamper() : void
+ TGPanel()
+ update(Graphics) : void
+ updateDrawPos(Node) : void
+ updateDrawPositions() : void
+ updateGraphSize() : void
+ updateLocalityFromVisibil ity() : void
+ updatePosFromDraw(Node) : void
~tgPanel
~lbNode
+from
+to
~dragNode
-completeEltSet
#mouseOverN
~tgPanel
#lbNodeDialog
#mouseOverE
#select
~completeEltSet
~graphEltSet
Figura 5.11. Diagrama de clases para la generación de estructuras de sitios Web
Capítulo 5. Implementación
Página 82
5.2.2.6. Generar reporte de errores El caso de uso equivalente a este módulo es CU-5 Crear reporte de errores. Para generar el reporte de errores de la estructura se creó la clase Report (figura 5.12), que contiene al método checkNodes, encargado de revisar el archivo XML, haciendo una enumeración de los elementos del EDGESET. TGLinkBrowser se encarga de enviar a la clase Report el nombre del archivo que desea verificar, el cual se encuentra almacenado en la variable Global.openedFile.
Por medio de ciclos, el mpetodo checkNodes, revisa primero el nodo origen de una
tripleta y después el nodo destino, hasta recorrer el grafo completo. Como resultado se obtiene un vector con las tripletas incorrectas que es enviado de vuelta a TGLinkBrowser.
Figura 5.12. Diagrama de clases para la generación de reporte de errores
La figura 5.13 muestra el diagrama de actividades para la generación del reporte de errores.
class client
Edge
LBEdge
+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}
+ DEFAULT_TYPE: int = 1
+ edgeType: int
+ HIERARCHICAL_EDGE: int = 1 {readOnly}
- label: String
+ LABEL_BACK_COLOR: Color = new Color(255, ...
+ LABEL_FONT: Font = new Font("Couri...
+ LABEL_TEXT_COLOR: Color
+ getLabel() : String
+ getType() : int
+ LBEdge(LBNode, LBNode)
+ LBEdge(LBNode, LBNode, int)
+ paint(Graphics, int, int, int, int, Color, int) : void
+ paint(Graphics, TGPanel) : void
+ paintEdgeBody(Graphics, TGPanel) : void
+ paintFatLine(Graphics, int, int, int, int, Color) : void
+ setEdgeDafaultType(int) : void
+ setLabel(String) : void
+ setType(int) : void
Report
~ contEdge: int = 0
~ graphEltSet: GraphEltSet
~ newEdge: LBEdge
~ parameterHash: Hashtable
~ tgPanel: TGPanel
~ v: Vector
- checkNodes(IXMLElement) : Vector
- getBooleanAttr(IXMLElement, String, boolean) : boolean
+ read(String, InputStream) : Vector
+ Report(GraphEltSet, TGPanel)
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
Node
LBNode
~ hint: String
+ HINT_BACK_COLOR: Color
+ HINT_FONT: Font = new Font("Couri...
+ HINT_TEXT_COLOR: Color
~ hintFont: Font
~ hintHeight: int
~ hintIsHTML: boolean
~ hintWidth: int
+ MINIMUM_HINT_HEIGHT: int = 20
~ url: String
~ urlIsLocal: boolean
~ urlIsXML: boolean
+ getHeight() : int
+ getHint() : String
+ getHintHeight() : int
+ getHintIsHTML() : boolean
+ getHintWidth() : int
+ getPaintBackColor(TGPanel) : Color
+ getPaintBorderColor(TGPanel) : Color
+ getPaintTextColor(TGPanel) : Color
+ getPaintUnselectedBackColor() : Color
+ getURL() : String
+ getURLIsLocal() : boolean
+ getURLIsXML() : boolean
+ getWidth() : int
+ LBNode()
+ LBNode(String)
+ LBNode(String, String, String)
~ myBrighter(Color) : Color
+ paint(Graphics, TGPanel) : void
+ separatorString(String) : String
+ setHint(String) : void
+ setHintHeight(int) : void
+ setHintIsHTML(boolean) : void
+ setHintWidth(int) : void
+ setNodeHintBackColor(Color) : void
+ setNodeHintFont(Font) : void
+ setNodeHintTextColor(Color) : void
+ setURL(String) : void
+ setURLIsLocal(boolean) : void
+ setURLIsXML(boolean) : void
~newEdge
Capítulo 5. Implementación
Página 83
Figura 5.13. Diagrama de actividades para la generación de reporte de errores
5.2.2.7. Validar la estructura de sitio Web Este módulo tiene su equivalente en el CU-6 Validar estructura del sitio Web. La validación se realiza de modo que el usuario pueda percibir visualmente que existen inconsistencias en el grafo creado. Las inconsistencias pueden ser de dos tipos:
Nodos creados sin etiqueta: al crear un nodo se omite la asignación de un nombre, por
lo que en el grafo se observa únicamente el nombre de la clase a la que pertenece el
ejemplar.
Aristas creadas o modificadas con etiqueta indefinida: al crear una relación entre
nodos se establece como indefinida o se modifica su valor si no se sabe con exactitud
el tipo de relación existente entre los ejemplares.
Esta validación se lleva a cabo al momento de abrir un archivo XML cuando la clase TGLinkBrowser se encarga de llamar al método read de la clase XMLio. Otro modo de hacerlo es a través de la edición de los elementos del grafo, con la LBEdgeDialog.
La clase LBEdgeDialog en el método saveChangesAndHideDialog permite realizar cambios en el color de las aristas si éstas no están definidas. Esto se debe a que el método asigna los datos proporcionados en la ventana por el usuario a las propiedades de la arista en las clases Edge y LBEdge. Al cambiar el valor de la etiqueta label de la arista al valor de Indefinida, ocurre un cambio en la apariencia de la misma.
Capítulo 5. Implementación
Página 84
Figura 5.14. Diagrama de actividades para la validación de estructuras de sitios Web
Otro modo de validar ocurre en la clase LBNodeDialog, cuando, al agregar un nuevo
nodo se omite la inserción de una etiqueta con el nombre del nodo que debe almacenarse junto con las otras propiedades.
Figura 5.15. Diagrama de clases para la validación de estructuras de sitios Web
class client
JInternalFrame
LBEdgeDialog
- cboEdgeLabel: JComboBox
- cboEdgeType: JComboBox
- cmdCancel: JButton
- cmdOK: JButton
- lastEdgeColorButton: JButton
~ lbEdge: LBEdge
- lblEdgeColor: JLabel
- tfEdgeColor: JTextField
- tfEdgeLength: JTextField
~ tgPanel: TGPanel
- encodeColor(Color) : String
- initColorSelectors() : void
- initComponents() : void
+ LBEdgeDialog(TGPanel)
+ main(String[]) : void
+ saveChangesAndHideDialog() : void
- setEdgeColor(Color) : void
+ setLBEdge(LBEdge) : void
+ showDialog() : void
TGUserInterface
LBEditUI
~ dragAddNodeUI: LBDragAddNodeUI
~ dragNodeUI: DragNodeUI
~ edgePopup: JPopupMenu
~ hvDragUI: TGAbstractDragUI
~ ml: LBEditMouseListener
~ mml: LBEditMouseMotionListener
~ nodePopup: JPopupMenu
~ popupEdge: LBEdge
~ popupNode: LBNode
~ switchSelectUI: TGAbstractClickUI
~ tgLinkBrowser: TGLinkBrowser
~ tgPanel: TGPanel
+ activate() : void
+ deactivate() : void
+ LBEditUI(TGLinkBrowser)
- setUpEdgePopup() : void
- setUpNodePopup() : void
MouseAdapter
LBEditUI::LBEditMouseListener
~ LBEditMouseListener()
+ mouseClicked(MouseEvent) : void
+ mousePressed(MouseEvent) : void
+ mouseReleased(MouseEvent) : void
MouseMotionAdapter
LBEditUI::LBEditMouseMotionListener
~ LBEditMouseMotionListener()
+ mouseMoved(MouseEvent) : void
JPanel
TGLinkBrowser
+ arbolNodos: JTree
+ band: int = 0
+ bar: JScrollPane
~ completeEltSet: GraphEltSet = null
- documentBase: URL
- enclosingApplet: JApplet = null
- enclosingFrame: JFrame = null
~ externalFrame: String
~ graphsVisited: Stack = new Stack() {readOnly}
+ hvScroll: HVScroll
~ initialNodeName: String
# lbEdgeDialog: LBEdgeDialog
# lbNodeDialog: LBNodeDialog
+ lbPopup: JPopupMenu
+ listReport: JList
+ localityScroll: LocalityScroll
~ modeSelectPanel: JPanel
~ openFile: JButton = new JButton()
- parser: JenaParser = null
~ proxyServlet: String
+ rotateScroll: RotateScroll
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
~ targetFrame: String
~ textOntology: JTextField = new JTextField()
~ tgLensSet: TGLensSet
~ tgPanel: TGPanel
~ tgUIManager: TGUIManager
~ xmlFileName: String
~ xmlio: XMLio
+ zoomScroll: ZoomScroll
+ addElement(Vector) : void
- addUIs() : void
- buildLens() : void
- buildPanel() : void
- createParameterHash() : Hashtable
+ getDocumentBase() : URL
+ getTGPanel() : TGPanel
- jbInit() : void
- lblMenuBarPrincipal() : JMenuBar
+ main(String[]) : void
~ processNodeUrl(LBNode) : void
- restoreSavedParameters(Hashtable) : void
~ salir_ActionPerformed(ActionEvent) : void
~ scrollSelectPanel(String[]) : JPanel
+ setLocale(String, int) : void
+ TGLinkBrowser()
+ TGLinkBrowser(JApplet)
~ TGLinkBrowser(JFrame)
+ titles(String, int, int, int, int) : JLabel
XMLio
~ graphEltSet: GraphEltSet
~ parameterHash: Hashtable
- buildGraphEltSet(IXMLElement, Thread) : void
- encodeColor(Color) : String
- getBooleanAttr(IXMLElement, String, boolean) : boolean
+ getClassName() : String
+ getLocalDirName() : String
+ getParameterHash() : Hashtable
+ read(String) : void
+ read(URL) : void
+ read(String, Thread) : void
+ read(URL, Thread) : void
+ read(String, InputStream, Thread) : void
+ setParameterHash(Hashtable) : void
+ write(OutputStream) : void
~ XMLio(GraphEltSet)
~ml
~tgLinkBrowser
~mml
~xmlio
#lbEdgeDialog
Capítulo 6. Pruebas
El presente capítulo describe el plan de pruebas y su seguimiento para verificar la usabilidad de la metodología en la definición de estructuras de sitios Web basada en diseño de ontologías.
Capítulo 6. Pruebas
Página 86
6.1. Introducción
Este trabajo está enfocado al desarrollo de una metodología. Se presentarán únicamente las pruebas al editor que sirve para implementar la metodología propuesta y una pequeña prueba de usabilidad, utilizada más con propósitos de exploración que de validación
6.2. Hipótesis
Hipótesis nula a comprobar: se propone como hipótesis que a través de una metodología de construcción de sitios Web basada en principios de ontologías, se pueda agregar semántica a la estructura del sitio para que éste sea más fácil de comprender.
6.3. Prueba de usabilidad
6.3.1. Descripción de las pruebas
Para llevar a cabo las pruebas de usabilidad se tomarán en cuenta los siguientes pasos, basados en el test de guerrilla [Hassan 2003]: Desarrollo de la prueba: Para llevar a cabo las pruebas se proporcionó, a cada participante, un documento donde se describe la ontología, sus conceptos y relaciones, así como ejemplos del uso de los mismos. Esto se hizo con la finalidad de entrenar previamente al usuario antes del desarrollo de la prueba. Posteriormente se procedió a realizar una serie de preguntas en base a las características a probar, con lo que se obtuvieron datos sobre el desempeño de los participantes al momento de desarrollar sus tareas.
Rango de éxito Para la evaluación del rango de éxito obtenido se tomaron en cuenta las siguientes actividades:
Comprensión de la información sobre las clases: indica si el usuario tiene un
entendimiento de la taxonomía propuesta en la ontología. Las clases y subclases, así
como la manera en que un ejemplar puede catalogarse dentro de una clase definida.
Clasificación de ejemplares en las clases proporcionadas: se refiere a si el usuario es
capaz o no de clasificar un elemento de sitio Web (tipos de página) dentro de alguna
clase de las propuestas en la taxonomía.
Comprensión de la información de las relaciones: esta actividad reporta si el usuario
es capaz de entender el significado de las relaciones, así como la manera en que puede
Capítulo 6. Pruebas
Página 87
aplicarlas. Las restricciones que se presentan para cada relación y el modo en que las
características le ayudan a la construcción del sitio Web.
Etiquetado de enlaces con las relaciones propuestas: esta actividad reporta si el
usuario tiene la capacidad de elegir, de entre las múltiples relaciones, aquella que es
útil para enlazar dos nodos con características determinadas o si existen enlaces que
son imposibles de etiquetar pues no existe un modo de clasificarlas dentro de las
relaciones propuestas.
Facilidad de estructuración: se refiere a la facilidad que muestra el usuario al
momento de construir una estructura de sitio Web con los elementos proporcionados.
Comprensión de la estructura etiquetada: indica si el usuario es capaz de entender
mejor la estructura etiquetada con relaciones.
Actividad A B C D E F G
Comprensión de la información sobre las clases P P E E P E E Clasificación de ejemplares con las clases proporcionadas P P E E P P E Compresión de la información sobre las relaciones P P E E E E E Etiquetado de enlaces con las relaciones propuestas E E E E E E E Facilidad de estructuración E E E E E E E Comprensión de la estructura etiquetada E E E E E E E
Éxito parcial Éxito completo Rango de éxito (RE) Número de intentos para lograr las tareas (NI): 42 Número de éxitos parciales (NEP): 9 Número de éxitos completos (NEC): 33
6.3.2. Problemas encontrados
A partir de la prueba realizada se encontró una serie de inconsistencias en la ontología creada, lo que favoreció a su reestructuración y formalización.
Los detalles encontrados se listan a continuación:
Capítulo 6. Pruebas
Página 88
Los usuarios tenían dificultades para clasificar algunos ejemplares dentro de alguna
de las clases proporcionadas en la ontología, por lo que se dieron a la tarea de realizar
modificaciones a las mismas, de manera que se adecuaran a sus necesidades.
La mayoría de los usuarios pudo emplear las relaciones proporcionadas, aunque
algunos debieron leer varias veces la información de manera que quedara claro su
uso.
Algunos usuarios consideraron ambiguas las clases, lo cual generaba confusión al
momento de clasificar.
Para corregir las deficiencias presentadas se hizo la nueva clasificación, que se muestra en esta tesis, la cual incluyen ejemplos de instancias para las clases .Se agregó una descripción, características y restricciones para su aplicación, de modo que su uso fuera más claro.
6.4. Plan de pruebas
Los distintos casos de prueba para validar el funcionamiento del editor de sitios Web EDWEB se basan en el estándar IEEE 829 [Std829 07].
6.4.1. Características a probar
A continuación se listan las actividades desarrolladas durante la prueba:
Pruebas de creación y edición de grafos: se creará un grafo manual con componentes
de la ontología o automáticamente, indicando el archivo XML a partir del cual se
genera. Se verificará la correcta creación del grafo. Debe generarse un reporte de
enlaces no definidos, en caso de que existan.
Pruebas de creación de estructuras de sitios: se creará una estructura de un sitio Web
basada en un grafo creado previamente. La estructura contará con páginas enlazadas.
6.4.1.1. Pruebas de creación y edición de grafos
EDWEB-101 Pruebas de creación y edición de grafos.
EDWEB-101-001 Carga de la ontología.
EDWEB-101-002 Crear grafo del sitio Web.
EDWEB-101-003 Crear archivo XML a partir de un grafo.
EDWEB-101-004 Generar grafo a partir de un archivo XML.
EDWEB-101-005 Crear reporte de enlaces.
EDWEB-101-006 Validar estructura del sitio Web.
Capítulo 6. Pruebas
Página 89
6.4.1.2. Pruebas de creación de estructuras de sitios Web EDWEB-102 Pruebas de creación de estructuras de sitios Web.
EDWEB-102-001 Generar estructura del sitio Web.
6.4.2. Procedimiento de las pruebas
Este apartado contiene la descripción de los procedimientos correspondientes a cada caso de prueba propuesto en el plan de pruebas. Los casos se organizan en grupos para validar y verificar una determinada funcionalidad.
Los grupos de pruebas contienen tareas que se encargan de la validación y verificación de aspectos funcionales de la herramienta de software EDWEB. Para cada grupo de pruebas se describe el propósito del caso, el entorno de desarrollo del mismo, el procedimiento para llevar a cabo la prueba y los resultados que se obtienen a partir de ella. 6.4.2.1. EDWEB-101 Pruebas de creación y edición de grafos
Propósito Verificar la creación y modificaciones sobre grafos, así como el almacenamiento de datos y la visualización que se pueden realizar sobre ellos. Entorno de prueba PC o laptop
EDWEB-101-001 Carga de la ontología
Propósito Tener disponibles los componentes para la creación de grafos manuales (clases de la ontología). Entorno de prueba PC o laptop Proceso
Abrir el editor de estructuras de sitios Web, Seleccionar el archivo OWL de la ontología, Cargar las clases de la ontología contenidas en el archivo OWL.
Resultado esperado Las clases hoja de la taxonomía de clases que conforma la ontología se listan en un árbol que el usuario puede utilizar para la creación del grafo.
Capítulo 6. Pruebas
Página 90
EDWEB-101-002 Crear grafo del sitio Web
Propósito Crear un nuevo archivo descriptivo de un sitio Web que se visualiza como un grafo compuesto por clases y relaciones tomadas del conjunto de elementos propuestos. Entorno de prueba PC o laptop.
Proceso
Cargar la ontología. Seleccionar una clase de la lista y una relación del menú de relaciones. Elaborar una tripleta. Repetir el proceso de generación de tripletas hasta completar el grafo.
Resultado esperado
Es posible generar tripletas válidas de acuerdo a las restricciones dadas por la ontología.
Es posible visualizar el grafo cuando se genera.
EDWEB-101-003 Crear archivo XML a partir de un grafo
Propósito Guardar la estructura de datos XML del grafo creado manualmente para su posterior uso en la generación de la estructura de sitios Web. Entorno de prueba PC o laptop Proceso
Tras haber creado un grafo, seleccionar la opción de guardar el grafo. El archivo de la estructura del grafo se almacena en la carpeta de datos.
Resultado esperado
La estructura de datos XML se crea basándose en el archivo DTD.
La estructura de datos XML se almacena correctamente en la ubicación
deseada.
EDWEB-101-004 Generar grafo a partir de un archivo XML
Propósito Generar un grafo de sitio Web automáticamente a partir del archivo de datos XML que lo describe.
Capítulo 6. Pruebas
Página 91
Entorno de prueba PC o laptop Proceso
El usuario abrirá la aplicación. Elegirá una opción para abrir grafo existente. Seleccionará la carpeta que contiene el archivo deseado. La aplicación interpreta el archivo descriptivo. Se generará el grafo.
Resultado esperado Se genera un grafo etiquetado con relaciones definidas por el archivo XML o con relaciones indefinidas, donde los nodos representan a las páginas HTML y las aristas a los enlaces entre ellas.
EDWEB-101-005 Crear reporte de errores
Propósito Verificar que los enlaces entre los nodos del grafo tengan relaciones definidas. Entorno de prueba PC o laptop Proceso
Ejecutar la aplicación. Tras haber creado un nuevo grafo o seleccionar uno existente, seleccionar del
menú la opción para verificar grafo. Reportar tripletas inconsistentes en el grafo.
Resultado esperado
Se despliega el mensaje de grafo relacionado correctamente.
Se genera el reporte que indica inconsistencias en ciertas tripletas del grafo.
EDWEB-101-006 Validar estructura del sitio Web
Propósito Mostrar al usuario de manera visual que el grafo es inconsistente en algunos de sus elementos. Entorno de prueba PC o laptop Proceso
Ejecutar la aplicación. Crear un nuevo grafo o abrir un grafo existente.
Capítulo 6. Pruebas
Página 92
Los elementos inconsistentes como aristas indefinidas o nodos sin etiquetas se visualizan de un tono magenta.
Resultado esperado
Los conceptos y relaciones indefinidos se visualizan de color magenta.
6.4.2.2. EDWEB-102 Pruebas de creación de estructuras de sitios Web
Propósito Revisar que sea posible generar un conjunto de páginas basadas en un grafo del sitio Web. Entorno de prueba PC o laptop.
EDWEB-102-001 Generar estructura del sitio Web
Propósito Verifica que después de revisar la estructura, sea posible crearla correctamente. La estructura debe contener un conjunto de páginas. Entorno de prueba PC o laptop. Proceso Abrir el editor de estructuras de sitios Web. Crear un nuevo grafo o abrir uno existente. Ejecutar el caso EDWEB-101-005 Reportar enlaces indefinidos para revisar los enlaces en el grafo del sitio. Seleccionar del menú la opción para generar HTML y crear la estructura. Resultado esperado Se creará una estructura del sitio Web, con un conjunto de páginas enlazadas entre sí.
6.4.3. Resultados de las pruebas
En este apartado se muestran algunos ejemplos de aplicación de la metodología a través de la herramienta EDWEB. Se presentan los resultados de cada caso de prueba con un escenario de éxito en las pruebas desarrolladas.
Capítulo 6. Pruebas
Página 93
Tabla 6.1. Caso de prueba EDWEB-101-001 Carga de la ontología
Caso de prueba: EDWEB-101-001 Carga de la ontología
Resultado: OK Archivo OWL seleccionado
Conjunto de clases listadas:
Observaciones: es posible cargar cualquier ontología almacenada en un archivo OWL, lo que permite observar las clases hijas de dicha ontología en forma de lista. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Capítulo 6. Pruebas
Página 94
Tabla 6.2. Caso de prueba EDWEB-101-002 Crear un grafo manual
Caso de prueba: EDWEB-101-002 Crear un grafo manual
Resultado: OK Formación de tripleta
Observaciones: Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Tabla 6.3. Caso de prueba EDWEB-101-003 Generar un archivo XML
Caso de prueba: EDWEB-101-003 Generar un archivo XML
Resultado: OK Selección de menú
Clase
Ejemplar
Relación
Guardar grafo
Capítulo 6. Pruebas
Página 95
Archivo a guardar
Archivo XML generado
Nombre del archivo
Capítulo 6. Pruebas
Página 96
Observaciones: los conceptos deben tener un nombre al momento de ser guardados, ya que esto repercute en el momento de la creación de una estructura basada en el grafo. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Tabla 6.4. Caso de prueba EDWEB-101-004 Generar un grafo automáticamente
Caso de prueba: EDWEB-101-004 Generar un grafo automáticamente
Resultado: OK Selección de menú
Archivo a graficar
Grafo generado a partir del archivo
Abrir grafo existente
Archivo
Grafo
Capítulo 6. Pruebas
Página 97
Observaciones: Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Tabla 6.5. Caso de prueba EDWEB-101-005 Reportar enlaces indefinidos
Caso de prueba: EDWEB-101-005 Reportar enlaces indefinidos
Resultado: OK Grafo con etiquetas indefinidas en las aristas
Reporte de tripletas indefinidas
Observaciones: se valida únicamente el uso de relaciones válidas, aunque pudieran considerarse algunas otras características definidas en la metodología. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Grafo
Tripletas indefinidas
Capítulo 6. Pruebas
Página 98
Tabla 6.6. Caso de prueba EDWEB-101-006 Validar el grafo
Caso de prueba: EDWEB-101-006 Validar el grafo
Resultado: OK Grafo correctamente etiquetado
Edición de una arista para mostrar la etiqueta indefinida
Valor indefinido
para la arista
Arista resultante
Capítulo 6. Pruebas
Página 99
Nodo con etiqueta
Observaciones: Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Tabla 6.7. Caso de prueba EDWEB-102-001 Generar estructura del sitio Web
Caso de prueba: EDWEB-102-001 Generar estructura del sitio Web
Resultado: OK Grafo etiquetado
Valor indefinido
para el nodo
Capítulo 6. Pruebas
Página 100
Carpeta creada para el grafo etiquetado
Ejemplo de página con enlaces
Observaciones: una relación indefinida no afecta en la creación de la estructura, pero sí la falta de definición de los ejemplares. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.
Capítulo 6. Pruebas
Página 101
La tabla 6.8 muestra una descripción de los grafos para los casos de prueba de la herramienta EDWEB.
Tabla 6.8. Descripción de grafos de los casos de prueba de la herramienta EDWEB Caso de prueba Nodo origen Nodo destino Relación
EDWEB-101-002 UnidadOrganizacional: * UnidadOrganizacional: Principal (F) Meronimia canónica-canónica
EDWEB-101-004 UnidadOrganizacional: Departamento CC
DescripciónAbstracta: Presentación
(A) Meronimia facultativa-facultativa
UnidadOrganizacional: Departamento CC
UnidadOrganizacional: Sistemas Distribuidos
(I) Meronimia canónica-canónica
UnidadOrganizacional: Departamento CC
DescripciónFísica: Infraestructura (G) Meronimia canónica-canónica
UnidadOrganizacional: Departamento CC
UnidadOrganizacional: PersonalAcadémico
(I) Meronimia canónica-canónica
EDWEB-101-005 UnidadOrganizacional: Principal OrganizaciónFuncionamiento: Departamento de CC
Indefinida
OrganizaciónFuncionamiento: Departamento de CC
Trabajador: Dr. Juan Gabriel Indefinida
OrganizaciónFuncionamiento: Departamento de CC
Trabajador: Dr. José Antonio Indefinida
EDWEB-101-006 UnidadOrganizacional: SistemasDistribuidos
UnidadOrganizacional: Posgrado (F) Meronimia canónica-canónica
UnidadOrganizacional: SistemasDistribuidos
UnidadOrganizacional: Publicaciones
(I) Meronimia canónica-canónica
UnidadOrganizacional: Posgrado OrganizaciónFuncionamiento: Plan de estudios
(E) Meronimia canónica-canónica
UnidadOrganizacional: Publicaciones
Producto: Artículo (D) Meronimia colección-miembro
UnidadOrganizacional: Sistemas Distribuidos
UnidadOrganizacional: Posgrado Indefinida
UnidadOrganizacional: Sistemas Distribuidos
Servicio: * Indefinida
EDWEB-102-001 Grafo del caso EDWEB-101-004
Nota: * denomina un nodo sin nombre de ejemplar definido.
Capítulo 7. Conclusiones Este capítulo resume las conclusiones obtenidas como resultado de la investigación, las aportaciones y propuestas de trabajos que podrían derivarse en el futuro a partir de de la metodología desarrollada.
Capítulo 6. Conclusiones
Página 103
7.1. Conclusiones
A continuación se listan las conclusiones obtenidas a partir de la investigación realizada:
1. No se encontraron otras herramientas o metodologías que permitan establecer
semántica a la estructura de un sitio Web, por lo cual este trabajo es pionero en su
campo. Las herramientas analizadas proveen patrones de diseño referentes a la
estética del sitio, otras herramientas se basan en el contenido de las páginas para
generar aplicaciones Web, mejorando la explotación de la información.
2. Se encontraron trabajos donde se expresa que existen relaciones implícitas en la
estructura de un sitio Web, siendo éstas de asociación y de agregación. Sin embargo,
no se define claramente ni se fundamenta su uso, ni los casos en que es posible
utilizarlas, ya que no se aplican de manera práctica.
3. Es posible relacionar conceptos en sitios Web del dominio de educación con relaciones
léxicas, entre ellas una de interés particular fue la meronimia. Algunos problemas
presentados con los tipos de meronimias encontrados se refieren al hecho de que es
posible aplicarlos en entidades tangibles, siendo difícil relacionar objetos abstractos
como los que representan algunas páginas, por lo que fue necesario integrar ciertas
propiedades que permitieran una adaptación de los tipos encontrados.
4. Los metadatos que se propone se agreguen a las páginas HTML (por ejemplo, autor,
tema, entre otras), no son suficientes para describir la estructura de un sitio Web.
7.2. Aportaciones
El trabajo que se presenta en esta tesis ofrece dos aportaciones: a) una definición de conceptos acerca de la arquitectura de sitios Web que se encuentran en el dominio de educación; b) proporciona un enfoque del uso del diseño de ontologías dentro de esta área.
7.3. Trabajos futuros
El trabajo de investigación presentado comprende el desarrollo de una metodología genérica que permite la creación de estructuras de sitios Web, así como su implementación en una herramienta de edición de sitios Web a través del uso de grafos. Algunas propuestas de trabajos que podrían desprenderse de esta tesis se listan a continuación:
Encontrar nuevos patrones de diseño, conceptos y relaciones que ayuden en el
enriquecimiento de la ontología propuesta, de manera que su uso pueda compartirse
a otros dominios de sitios Web o aplicaciones.
Automatizar el proceso de creación de la ontología, ya que la obtención de los
conceptos y relaciones fue un proceso manual que comprendió un periodo de cuatro
Capítulo 6. Conclusiones
Página 104
meses aproximadamente. Es posible obtener una automatización de una buena parte
de la creación de la ontología que aminore el tiempo de análisis y proporcione un
mayor contenido de información a través del estudio del contenido de sitios Web.
Realizar un estudio semántico que permita nombrar las relaciones y conceptos de
manera que brinden al usuario un mayor grado de comprensión.
Automatizar la generación de grafos de sitios Web, a través del análisis del contenido
de los documentos que lo componen, de manera que el etiquetado no se realice de
forma manual, cuando se necesite representar sitios con un gran número de páginas.
De esta manera se disminuye el tiempo y esfuerzo de operación de la herramienta.
7.4. Publicaciones
“Adapting Meronymy Relation to Define Properties among Web Site Objects”, presentado en The Fifteenth International Multi-Conference on Advanced Computer Systems (ACS 2008), a publicarse en Polish Journal of Environmental Studies, en Polonia. Indexado por el Science Citation Index SCI.
Página 105
Anexo A: Ejemplos de etiquetado
Los ejemplos de etiquetado mostrados a continuación fueron creados en base sitios de educación. Para una mejor comprensión de la estructura de los sitios Web se ha realizado el etiquetado por secciones.
A.1 Fragmento de grafo de la página principal del cenidet
Dominio Nodo del dominio
Rango Nodo del rango Relación
Unidad organizacional
Cenidet Unidad organizacional
Ingeniería Mecánica
(F) Meronimia canónica-canónica
Unidad organizacional
Cenidet Unidad organizacional
Ingeniería Mecatrónica
(F) Meronimia canónica-canónica
Unidad organizacional
Cenidet Unidad organizacional
Ingeniería Electrónica
(F) Meronimia canónica-canónica
Unidad organizacional
Cenidet Unidad organizacional
Ciencias Computacionales
(F) Meronimia canónica-canónica
Unidad organizacional
Cenidet Descripción abstracta
Presentación (K) Meronimia canónica-facultativa
Unidad organizacional
Cenidet Descripción física
Directorio (A) Meronimia facultativa-facultativa
Unidad organizacional
Cenidet Descripción física
Localización y traslado
(A) Meronimia facultativa-facultativa
Unidad organizacional
Cenidet Suceso Curso de actualización
Topológica
Página 106
A.2 Fragmento de grafo del departamento de Física del CINVESTAV
Dominio Nodo del
dominio Rango Nodo del rango Relación
Unidad organizacional
Departamento de Física
Unidad organizacional
Programa de maestría en ciencias (Física)
(A) Meronimia facultativa-facultativa
Unidad organizacional
Departamento de Física
Descripción abstracta
Principal A) Meronimia facultativa-facultativa
Unidad organizacional
Departamento de Física
Descripción física
Directorio A) Meronimia facultativa-facultativa
Unidad organizacional
Departamento de Física
Descripción física
Ubicación A) Meronimia facultativa-facultativa
Unidad organizacional
Departamento de Física
Unidad organizacional
Investigadores (I) Meronimia canónica-canónica
Unidad organizacional
Investigadores Trabajador Baquero Parra, Rafael
(C) Meronimia grupo-miembro
Unidad organizacional
Investigadores Trabajador Bretón Báez, Nora Eva
(C) Meronimia grupo-miembro
Página 107
Anexo B: Implementación
Código de carga de la ontología import com.hp.hpl.jena.ontology.Individual;
import com.hp.hpl.jena.ontology.OntClass;
import com.hp.hpl.jena.rdf.model.Resource;
TGLinkBrowser(JFrame f){
...
JScrollPane panelTree;
panelTree= new JScrollPane();
List<OntClass> listClass=null;
List<Individual> listIndividuals=null;
JFileChooser fileChooser = new JFileChooser();
fileChooser.addChoosableFileFilter(new FileNameExtensionFilter("owl","OWL"));
int value = fileChooser.showOpenDialog(this);
Iterator<OntClass> itClass;
if ( value == JFileChooser.APPROVE_OPTION ){
File file = fileChooser.getSelectedFile();
textOntology.setText(file.getAbsolutePath());
parser = new JenaParser(file);
listClass = parser.getOntClass();
listIndividuals = parser.getIndividuals();
}
if ( parser != null ){
DefaultMutableTreeNode nodeRoot = new DefaultMutableTreeNode( );
nodeRoot.setUserObject("Class");
itClass= listClass.iterator();
while ( itClass.hasNext()){
Resource resource = itClass.next();
DefaultMutableTreeNode node = new DefaultMutableTreeNode( );
node.setUserObject(resource.getLocalName());
if ((resource.getLocalName())!=null)
{ nodeRoot.add(node);}
}
DefaultTreeModel modelTree = new DefaultTreeModel( nodeRoot );
JTree JTreeReasoner = new JTree(modelTree);
JTreeReasoner.getSelectionModel().setSelectionMode
TreeSelectionModel.SINGLE_TREE_SELECTION);
TreeSelectionListener selTree= new TreeSelectionListener(){
public void valueChanged(TreeSelectionEvent e){
DefaultMutableTreeNode nodeSelected = (DefaultMutableTreeNode)
e.getPath().getLastPathComponent();
Global.newNode1=nodeSelected.toString();
}
...
}
enclosingFrame= f;
xmlFileName=null;
...
}
Página 108
Creación de un nodo TGPanel tgPanel;
/**
* @Method: TGLinkBrowser
* @Description: constructor con frame
* @Param: f
* @Return:
*/
TGLinkBrowser(JFrame f){
this();
...
try
{
tgPanel.addNode(new LBNode("UnidadOrganizacional:Principal"));
}
catch (TGException e)
{e.printStackTrace();}
}
Propiedades del nodo
public LBNode(String s, String s1, String s2)
{
super(s, s1);
urlIsLocal = false;
urlIsXML = false;
hintIsHTML = false;
hintWidth = 300;
hintHeight = -1;
url = s2;
hint = "";
hintFont = HINT_FONT;
}
Creación de una relación public class Edge {
public Edge(Node node, Node node1, int i)
{
from = node;
to = node1;
length = i;
col = DEFAULT_COLOR;
}
}
Método validate de la clase Validator /**
* @Method: validate
* @Description: valida que la tripleta formada sea correcta
* @Param: lNode, nNode, rel
* @Return: boolean (true/false)
* */
public boolean validate(String lNode, String nNode, String rel)
{
LBNode lNodeTemp=new LBNode(lNode);
LBNode nNodeTemp=new LBNode(nNode);
lNode= lNodeTemp.separatorString(lNode);
nNode= nNodeTemp.separatorString(nNode);
Página 109
if (rel.equals("Indefinida"))
{return true;}
else
{
if (lNode.equals("UnidadOrganizacional"))
{
if (nNode.equals("OrganizacionFuncionamiento"))
{
if ((rel.equals("Meronimia A"))||(rel.equals("Meronimia E")))
{return true;}
if (rel.equals("Meronimia E"))
{return true;}
}
...
}
...
return false;
}//Fin de la función validate
Método saveChangesAndHideDialog de la clase LBNodeDialog
/***
* @Method: saveChangesAndHideDialog
* @Description: guarda los cambios al nodo una vez que la ventana
* se ha cerrado
* @Param:
* @Return:
* */
public void saveChangesAndHideDialog()
{
String receivedCad;
if(lbNode == null)
{
setVisible(false);
return;
}
String value=tfURL.getText();
if((value.trim().equals("")==false)&&(value.trim()!=null))
{
lbNode.setURL(tfURL.getText());
receivedCad=lbNode.separatorString(Global.global2+":"+tfURL.getText());
lbNode.setLabel(receivedCad+":"+tfURL.getText());
lbNode.setURLIsXML(cbXML.isSelected());
lbNode.setURLIsLocal(cbLocal.isSelected());
lbNode.setTextColor(lblTextColor.getBackground());
Node.setNodeTextColor(lblTextColor.getBackground());
if ((lblBackColor.getBackground())==(Color.magenta))
{
lbNode.setBackColor(Color.BLACK);
Node.setNodeBackDefaultColor(Color.BLACK);
}
else
{
lbNode.setBackColor(lblBackColor.getBackground());
Node.setNodeBackDefaultColor(lblBackColor.getBackground());
}
lbNode.setHint(taHint.getText());
lbNode.setHintIsHTML(cbHintIsHTML.isSelected());
lbNode.setType(cboNodeType.getSelectedIndex() + 1);
Node.setNodeType(cboNodeType.getSelectedIndex() + 1);
try
{
lbNode.setHintWidth(Integer.parseInt(tfHintWidth.getText()));
}
catch(NumberFormatException numberformatexception) {
Página 110
System.out.println("Error");}
try
{
lbNode.setHintHeight(Integer.parseInt(tfHintHeight.getText()));
}
catch(NumberFormatException numberformatexception1) {
System.out.println("Error");}
try
{
lbNode.setFont(new Font(Node.TEXT_FONT.getFamily(), 0,
Integer.parseInt((String)cboFontSize.getSelectedItem())));
}
catch(NumberFormatException numberformatexception2)
{System.out.println("Error"); }
setVisible(false);
if(tgPanel != null)
tgPanel.repaint();
Global.newNode1=null;
}
else
{
JOptionPane.showMessageDialog(null, "Escriba un nombre para el nodo", "Error",
JOptionPane.WARNING_MESSAGE);
}
}
Método write de XMLio public void write(OutputStream out) throws Exception
{
XMLElement tglbXML = new XMLElement("TOUCHGRAPH_LB");
tglbXML.setAttribute("version", "1.20");
final XMLElement nodeSet = new XMLElement("NODESET");
tglbXML.addChild(nodeSet);
…
TGForEachNode fen = new TGForEachNode() {
public void forEachNode(Node node)
{
…
}
};
graphEltSet.forAllNodes(fen);
final XMLElement edgeSet = new XMLElement("EDGESET");
tglbXML.addChild(edgeSet);
TGForEachEdge fee = new TGForEachEdge() {
public void forEachEdge(Edge edge)
{
…
}
};
…
graphEltSet.forAllEdges(fee);
XMLElement parameters = new XMLElement("PARAMETERS");
tglbXML.addChild(parameters);
XMLElement param;
for(Enumeration paramNames = parameterHash.keys();
paramNames.hasMoreElements(); parameters.addChild(param))
{
String name = (String)paramNames.nextElement();
String value = (String)parameterHash.get(name);
param = new XMLElement("PARAM");
param.setAttribute("name", name);
param.setAttribute("value", value);
}
BufferedReader bReader = new BufferedReader(new FileReader(getLocalDirName() +
File.separatorChar + "TG_Prepend_DTD.xml"));
String thisLine;
Página 111
while ((thisLine = bReader.readLine()) != null)
{
out.write(thisLine.getBytes());
out.write((System.getProperty("line.separator")).getBytes());
}
XMLWriter writer = new XMLWriter(out);
writer.write(tglbXML, true);
out.close();
bReader.close();
}
Método read del archivo XMLio public void read(String fileName, InputStream in, Thread afterReading)throws Exception{
InputStream xmlStream;
if(fileName.toLowerCase().endsWith(".zip")){
xmlStream = new ZipInputStream(in);
((ZipInputStream)xmlStream).getNextEntry();
}
else
if(fileName.toLowerCase().endsWith(".gz"))
xmlStream = new GZIPInputStream(in);
else
xmlStream = in;
IXMLParser parser = new StdXMLParser();
parser.setBuilder(new StdXMLBuilder());
parser.setValidator(new NonValidator());
StdXMLReader reader = new StdXMLReader(xmlStream);
parser.setReader(reader);
IXMLElement tglbXML = null;
try{
tglbXML = (IXMLElement)parser.parse();
}
catch(Exception e){
e.printStackTrace();
}
xmlStream.close();
buildGraphEltSet(tglbXML, afterReading);
}
Método buildGraphEltSet de la clase XMLio private void buildGraphEltSet(IXMLElement tglbXML,Thread afterReading) throws TGException{
IXMLElement nodeSet = (IXMLElement)tglbXML.getChildrenNamed("NODESET").firstElement();
LBNode newNode;
for(Enumeration nodeEnum=nodeSet.enumerateChildren();
nodeEnum.hasMoreElements(); graphEltSet.addNode(newNode)){
IXMLElement node = (IXMLElement)nodeEnum.nextElement();
String nodeID = node.getAttribute("nodeID", null);
...
Vector v = node.getChildrenNamed("NODE_LOCATION");
if(!v.isEmpty()){
IXMLElement nodeLocation = (IXMLElement)v.firstElement();
int x = nodeLocation.getAttribute("x", 0);
int y = nodeLocation.getAttribute("y", 0);
newNode.setLocation(new Point(x, y));
newNode.setVisible(getBooleanAttr(nodeLocation, "visible", false));
}
...
IXMLElement edgeSet=(IXMLElement)tglbXML.getChildrenNamed("EDGESET").firstElement();
LBEdge newEdge;
for(Enumeration edgeEnum=edgeSet.enumerateChildren();
edgeEnum.hasMoreElements(); graphEltSet.addEdge(newEdge))
{
IXMLElement edge = (IXMLElement)edgeEnum.nextElement();
String fromID = edge.getAttribute("fromID", null);
String toID = edge.getAttribute("toID", null);
Página 112
int length = edge.getAttribute("length", 4000);
String label = edge.getAttribute("label", null);
LBNode fromNode = (LBNode)graphEltSet.findNode(fromID);
LBNode toNode = (LBNode)graphEltSet.findNode(toID);
newEdge = new LBEdge(fromNode, toNode, length);
Color color = LBEdge.DEFAULT_COLOR;
...
for(Enumeration paramEnum=parameters.enumerateChildren();
paramEnum.hasMoreElements();)
{
IXMLElement param = (IXMLElement)paramEnum.nextElement();
String name = param.getAttribute("name", null);
String value = param.getAttribute("value", null);
if(name != null)
parameterHash.put(name, value);
}
}
if(afterReading != null)
afterReading.start();
}
Método buildPages de la clase ParserHTML.
private void buildPages(IXMLElement tglbXML)throws TGException
{
IXMLElement nodeSet = (IXMLElement)tglbXML.
getChildrenNamed("NODESET").firstElement()
IXMLElement nodeSet1 = (IXMLElement)tglbXML.getChildrenNamed
("NODESET").firstElement();
IXMLElement edgeSet = (IXMLElement)tglbXML.getChildrenNamed
("EDGESET").firstElement();
LBNode newNode;
if (Global.openedFile!=null){
File directed= new
File("/C:/jdevjava10133/jdev/mywork/EDWEB/"+ (Global.openedFile).getName());
if (directed.exists()==false){
directed= new File
("/C:/jdevjava10133/jdev/mywork/EDWEB/"+ (Global.openedFile).getName());
directed.mkdir();
...
}
Método buildPages de la clase ParserHTML. private void buildPages(IXMLElement tglbXML)throws TGException {
...
for(Enumeration nodeEnum = nodeSet.enumerateChildren();
nodeEnum.hasMoreElements();){
IXMLElement node = (IXMLElement)nodeEnum.nextElement();
String nodeID = node.getAttribute("nodeID", null);
if(nodeID == null)
throw new TGException(3, "node has no ID");
newNode = new LBNode(nodeID, "", "");
Vector v = node.getChildrenNamed("NODE_URL");
if(!v.isEmpty()){
IXMLElement nodeLabel = (IXMLElement)v.firstElement();
newNode.setLabel(nodeLabel.getAttribute("url", ""));
try{
String fullFileName = directed.toString() + File.separatorChar
+(nodeLabel.getAttribute("url", "")) + ".html";
BufferedWriter bWriter = new
BufferedWriter(new FileWriter(fullFileName));
String label=nodeLabel.getAttribute("url", "");
String cad="<html><head><title>"+label+"</title></head><body>";
String cad1="</html>";
bWriter.write(cad);
Página 113
for (Enumeration edgeEnum = edgeSet.enumerateChildren();
edgeEnum.hasMoreElements();){
IXMLElement edge = (IXMLElement)edgeEnum.nextElement();
String fromID = edge.getAttribute("fromID", null);
if(fromID.equals(nodeID)){
String toID=edge.getAttribute("toID",null);
for(Enumeration nodeEnum1 = nodeSet1.
enumerateChildren(); nodeEnum1.hasMoreElements();){
IXMLElement node1 =IXMLElement)nodeEnum1.nextElement();
String nodeID1 = node1.getAttribute("nodeID", null);
if(toID.equals(nodeID1)){
Vector vec = node1.getChildrenNamed("NODE_URL");
if(!vec.isEmpty()){
IXMLElement nodeLabelTo=(IXMLElement)vec.firstElement();
String labelTo = nodeLabelTo.getAttribute("url","");
String fullFileName1 = directed.toString() +
File.separatorChar +labelTo+ ".html";
bWriter.write("<p><a href=file:///"+fullFileName1+" title="+
labelTo +" >"+ labelTo +"</a></p>");
}
}
}
}
}
bWriter.write(cad1);
bWriter.close();
BufferedReader bReader = new BufferedReader(new
FileReader("/C:/jdevjava10133/jdev/mywork/EDWEB/Client/"+
Global.openedFile.getName()));
String thisLine;
String copiedXML = directed.toString() + File.separatorChar +
Global.openedFile.getName();
BufferedWriter writerXML = new BufferedWriter(new FileWriter(copiedXML));
while ((thisLine = bReader.readLine()) != null){
writerXML.write(thisLine);
writerXML.write((System.getProperty("line.separator")));
}
XMLWriter writer = new XMLWriter(writerXML);
writer.write(tglbXML, true);
writerXML.close();
}
catch(IOException e) {System.out.println("Error 1");}
}
}
}
Método checkNodes de la clase Report.
private Vector checkNodes(IXMLElement tglbXML)throws TGException{
...
if (Global.openedFile!=null){
for(Enumeration nodeEnum = nodeSet.enumerateChildren();nodeEnum.hasMoreElements();){
IXMLElement node = (IXMLElement)nodeEnum.nextElement();
String nodeID = node.getAttribute("nodeID", null);
...
}
v = node.getChildrenNamed("NODE_URL");
if(!v.isEmpty()){
IXMLElement nodeURL = (IXMLElement)v.firstElement();
newNode.setURL(nodeURL.getAttribute("url", ""));
if ((nodeURL.getAttribute("url", "")).equals("")){
contNodes=contNodes+1;
}
newNode.setURLIsLocal(getBooleanAttr(nodeURL, "urlIsLocal", false));
newNode.setURLIsXML(getBooleanAttr(nodeURL, "urlIsXML", false));
}
}
if (contNodes>=1){
JOptionPane.showMessageDialog(null, "Existen "+contNodes+ " nodos sin etiquetar",
Página 114
"Error", JOptionPane.WARNING_MESSAGE);
Global.globalCont=contNodes;
}
for (Enumeration edgeEnum = edgeSet.enumerateChildren(); edgeEnum.hasMoreElements();){
IXMLElement edge = (IXMLElement)edgeEnum.nextElement();
String edgeLabel= edge.getAttribute("label","");
if (edgeLabel.equals("Indefinida")){
String fromID = edge.getAttribute("fromID", null);
String toID = edge.getAttribute("toID", null);
int length = edge.getAttribute("length", 4000);
for(Enumeration nodeEnum1 = nodeSetFrom.enumerateChildren();
nodeEnum1.hasMoreElements();){
IXMLElement node = (IXMLElement)nodeEnum1.nextElement();
String newNodeFrom = node.getAttribute("nodeID", null);
if(newNodeFrom == null)
throw new TGException(3, "node has no ID");
Vector v;
v = node.getChildrenNamed("NODE_LABEL");
if(!v.isEmpty()){
IXMLElement nodeLabelFrom = (IXMLElement)v.firstElement();
if (newNodeFrom.equals(fromID)){
classFrom = nodeLabelFrom.getAttribute("label","");
}
}
}
for(Enumeration nodeEnum2 = nodeSetTo.enumerateChildren();
nodeEnum2.hasMoreElements();){
...
IXMLElement nodeLabelTo = (IXMLElement)v.firstElement();
if (newNodeTo.equals(toID)){
classTo = nodeLabelTo.getAttribute("label","");
}
}
}
returnedCad=("Arista con etiqueta indefinida del nodo"+classFrom+"al nodo"+classTo);
returnEdge.add(returnedCad);
contEdges= contEdges+1;
...
}
...
if (contEdges==0){
returnedCad =("El grafo está relacionado correctamente");
returnEdge.add(returnedCad);
}
...
}
Método saveChangesAndHideDialog de la clase LBNodeDialog.
public void saveChangesAndHideDialog()
{
if(lbEdge == null){
setVisible(false);
return;
}
Node nodeTo=new LBNode();
nodeTo=lbEdge.getTo();
Node nodeFrom=new LBNode();
nodeFrom=lbEdge.getFrom();
Validator validateTripleta= new Validator();
Boolean result= (validateTripleta.validate(nodeFrom.getLabel(),
nodeTo.getLabel(),(String)cboEdgeLabel.getSelectedItem()));
if (result==true){
lbEdge.setLabel((String)(cboEdgeLabel.getSelectedItem()));
if ((cboEdgeLabel.getSelectedItem().equals("Indefinida"))&&
(lblEdgeColor.getBackground()==(Color.magenta))){
lbEdge.setColor(Color.magenta);
Edge.setEdgeDefaultColor(Color.magenta);
}
Página 115
else{
if(((cboEdgeLabel.getSelectedItem().equals("Indefinida"))==false)&&
(lblEdgeColor.getBackground()==(Color.magenta))){
lbEdge.setColor(Color.decode("#0000B0"));
Edge.setEdgeDefaultColor(Color.decode("#0000B0"));
}
else{
if(((cboEdgeLabel.getSelectedItem().equals("Indefinida")))&&
(lblEdgeColor.getBackground()!=(Color.magenta))){
lbEdge.setColor(Color.magenta);
Edge.setEdgeDefaultColor(Color.magenta);
}
else{
if(((cboEdgeLabel.getSelectedItem().equals("Indefinida"))==false)&&
(lblEdgeColor.getBackground()!=(Color.magenta))){
lbEdge.setColor(lblEdgeColor.getBackground());
Edge.setEdgeDefaultColor(lblEdgeColor.getBackground());
...
}
...
}
Página 116
Referencias [ADOBE 07] Adobe; [En línea]; [Accedido el 21 de septiembre de 2007]; Disponible en:
“http://livedocs.adobe.com/dreamweaver/8_es/using/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=05_sit27.htm”.
[BRAIN 04] TheBrain Technologies Corporation; The Brain, Personal Brain. User guide; 2004; [En línea]; [Accedido el 21 de septiembre del 2007]; Disponible en: “http://www.thebrain.com/site/personalbrain/support/PersonalBrain_3_02_User_Guide.pdf”.
[BRAIN 07] The Brain. Visual Information Management; [En línea]; [Accedido el 17 de junio del 2007]; Disponible en línea en el World Wide Web en: “http://www.thebrain.com/#-42”.
[CAÑAS 03] Cañas A. J., Coffey J. W., Carnot M. J., Feltovich P. J., Hoffman R. R, Novak J. D.; “A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support”; Technical Report submitted to the US Navy Chief of Naval Education and Training; Institute for Human and Machine Cognition (IHCM); Pensacola, Florida; july 2003.
[COOLEY 00] Cooley R., Tan P., Srivastava J.; “Discovery of interesting usage patterns from Web data”; Lecture notes in computer science: Web usage analysis and user profiling 1836/2000; ISSN 0302-9743 (Print) 1611-3349 (Online), pp. 163-182; 2000.
[CRUSE 86] Cruse D. A; “Lexical Semantics”; Cambridge University Press; 1986. [DÍEZ 99] Díez P.L.; “La relación de meronimia en los sustantivos del léxico español:
contribución a la semántica computacional”, Estudios de lingüística española, 2; ISSN 1139-8736; 1999.
[FONS 02] Fons J. J., Pastor O., Valderas P., Ruiz M.; 2002; “OOWS: un Método de Producción de Software en Ambientes Web”; Avances en Comercio Electrónico 9; ISBN 84-607-5827-3; pp. 119-136.
[GUIZZARDI 05] Guizzardi G; Ontological foundations for structural conceptual models; Telematica Instituut Fundamental Research Series No. 15; ISBN 90-75176-81-3 ISSN 1388-1795, No. 015. CTIT PhD-thesis; ISSN 1381-3617, No. 05-74; 2005.
[GREENWICH 07] University of Greenwich; Website Arquitecture, Masters Programme at the University of Greenwich, [En línea]; [Accedido el 15 de abril de 2007]; Disponible en: http://www.Websitearchitecture.co.uk/define/index.php.
[GRUBER 93] Gruber T.; “A Translation Approach to Portable Ontology Specifications”; Knowledge Acquisition 5(2); ISSN: 1042-8143; pp. 199-220, 1993.
[HASSAN 03] Hassan M., Martín F., Método de test con usuarios, 2003; [En línea]; [Accedido el 05 de agosto de 2008]; Disponible en: “http://www.nosolousabilidad.com/articulos/test_usuarios.htm”.
[IHCM 07] Institute for human and machine cognition (IHCM) CmapTools; [En línea]; [Accedido el 15 de abril de 2007]; Disponible en: “http://cmap.ihmc.us/”.
[INSFRÁN 98] Insfrán E., Pelechano V., Gómez J., Pastor O.; “Un estudio comparativo de la expresividad de relaciones entre clases en OO-Method y UML”, III Jornadas de Trabajo de MENHIR; Murcia, España; noviembre, 1998.
[JIN 01] Jin Y., Decker S., Wiederhold G.; “OntoWebber: Model-Driven Ontology-Based Web Site Management”; The 1st International Semantic Web Working Symposium (SWWS'01); Universidad de Stanford, Palo Alto, California; julio 29-agosto 1, 2001.
Página 117
[LEE 06] Lee W.; “Hierarchical Web Structuring from the Web as a Graph Approach with Repetitive Cycle Proof”; Lecture notes in computer science: Advanced Web and network technologies, and applications 3842/2006; ISSN 0302-9743 (Print) 1611-3349 (Online); pp. 1004-1011; 2006.
[LIECHTI 98] Liechti, O., Sifer M. J., Ichikawa T.; 1998; “Structured graph format: XML metadata for describing Web site structure”; Computer Networks and ISDN Systems 30; No. 1 (1998): pp. 11-21.
[Mc GUINESS 04] Deborah L. McGuinness, Frank van Harmelen. OWL Web Ontology Language Overview. W3C Recommendation 10 febrero 2004. En línea. http://www.w3.org/TR/2004/REC-owl-features-20040210/. Accedido el 23 de junio del 2008.
[MORVILLE 07] Morville P.; Semantic studios; [En línea]; [Accedido el 30 de junio del 2007]; Disponible en: http://semanticstudios.com/publications/semantics/ 000149.php.
[NETCRAFT 08] Netcraft; [En línea]; [Accedido el 27 de marzo del 2008]; Disponible en: “http://news.netcraft.com/archives/2008/03/26/march_2008_web_server_
survey.html”
[NIELSEN 03] Nielsen J.; Usability 101: Introduction to Usability. Jakob Nielsen´s Alertbox, 25 de agosto del 2003, [En línea] [Accedido el 02 de marzo del 2007; Disponible en: http://www.useit.com/alertbox/20030825.html
[NOVAK 84] Novak J. D., Gowin D. B.; “Learning How to Learn”; ISBN-10: 0521319269, ISBN-13: 978-0521319263; Cambridge University Press; september 28, 1984.
[OWL 08] W3C. OWL Web Ontology Languaje; [En línea]; [Accedido el 27 de marzo del 2007]; Disponible en: “http://www.w3.org/TR/owl-features/”.
[PLAISANT 97] Plaisant C., Marchionini G., Komlodi A.; 1997; “Visualizing websites using a hierarchical table of contents browser: WebTOC”; Third Conference on Human Factors and the Web.
[POWELL 02] Powell T. A.; “Web design. The complete reference”; 2nd edition; Mc Graw Hill/ Osborne; 2002.
[ROSENFELD 06] Rosenfeld L., Morville P.; “Information Architecture for the World Wide Web: Designing Large-Scale Web Sites”; ISBN 10: 0-596-52734-9; 3th. Edition; O’ Reilly Inc.; 2006.
[SAGER 90] Sager, J. C. “Practical Course in Terminology Processing”; Amsterdam; John Benjamins; Trad. Esp; 1990.
[SAUSSURE 83] Saussure F. de; “Curso de Lingüística General”; Alianza editorial; Madrid; 1983.
[SIDAR 08] Sidar Traducciones; [En línea]; [Accedido el 1 de Abril de 2008]; Disponible en: “http://www.sidar.org/recur/desdi/traduc/es/rdf/rdfesp.htm”.
[SIL 08] SIL. Paterns in language development; [En línea]; [Accedido el 29 de noviembre de 2007]; Disponible en: “http://www.sil.org/”.
[SIMIC 02] Simic H.; “Application of UriGraph to Uniform Resource Identifier design”; 4th CARNet Users Conference; Zagreb, Croatia; septiembre 25-27 2002.
[SIMIC 03] Simic H.; “Patterns of Web Site Structure in UriGraph”; 7th International Conference on Telecommunications; Zagreb, Croatia; junio 11-13 2003.
[TOUCHGRAPH 07a] TouchGraph; [En línea]; [Accedido el 20 de septiembre del 2007]; Disponible en línea en el World Wide Web en: “http://www.touchgraph.com/”.
[TOUCHGRAPH 07b] TouchGraph; [En línea]; [Accedido el 20 de septiembre del 2007]; Disponible en línea en el World Wide Web en: “http://touchgraph.cvs. sourceforge.net/touchgraph/src/com/touchgraph/wikibrowser”.
[UML 05] Unified Modeling Language Specification version 1.4.2. Disponible en línea http://www.omg.org/docs/formal/05-04-01.pdf. Enero 2005.
Página 118
[USCHOLD 96] Uschold M., Gruninger M.; 1996; “Ontologies: principles, methods and applications”; Knowledge Engineering Review 11; No. 2; pp 320-321.
[W3C 08] W3C. Semantic Web; [En línea]; [Accedido el 27 de marzo de 2008]; Disponible en: “http://www.w3.org/2001/sw/”.
[W3C 08b] Extensible Markup Language; [En línea]; [Accedido el 27 de junio del 2008]; Disponible en: “http://www.w3.org/XML/”.