Capítulo 6
Anuncio
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.
Índice de contenido
CAPÍTULO 1.
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
1.8.
INTRODUCCIÓN ..................................................................................................................... 1
ANTECEDENTES .......................................................................................................................................... 2
DESCRIPCIÓN DEL PROBLEMA ........................................................................................................................ 3
OBJETIVO.................................................................................................................................................. 3
JUSTIFICACIÓN ........................................................................................................................................... 4
ALCANCES ................................................................................................................................................. 5
LIMITACIONES ............................................................................................................................................ 5
BENEFICIOS ............................................................................................................................................... 6
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.
2.10.3.2.
2.10.3.3.
2.10.3.4.
Mereología ............................................................................................................................................14
Meronimias centrales ........................................................................................................................... 15
Meronimias no centrales ...................................................................................................................... 15
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 i
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.
3.7.2.2.
LinkBrowser...........................................................................................................................................33
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.
4.2.1.2.
4.2.2.
Análisis de sitios Web de dominio educación (edu) ..............................................................................39
Estructura de páginas ............................................................................................................................ 41
Construcción de una ontología del dominio de educación ............................................................ 44
4.2.2.1.
4.2.2.2.
4.2.2.3.
4.2.2.4.
4.2.2.5.
4.2.2.6.
Identificación del propósito de la ontología .......................................................................................... 44
Identificación de conceptos del dominio .............................................................................................. 44
Creación de la taxonomía de clases ......................................................................................................45
Atributos de las clases de la ontología ..................................................................................................47
Definición de clases de la taxonomía ....................................................................................................47
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.
5.2.2.2.
5.2.2.3.
5.2.2.4.
5.2.2.5.
5.2.2.6.
5.2.2.7.
CAPÍTULO 6.
Carga de la ontología............................................................................................................................. 72
Creación de grafos con la herramienta .................................................................................................73
Crear archivo XML a partir de un grafo .................................................................................................76
Generar grafo a partir de un archivo XML ............................................................................................. 78
Generar estructura del sitio Web ..........................................................................................................79
Generar reporte de errores ................................................................................................................... 82
Validar la estructura de sitio Web .........................................................................................................83
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 ii
Características a probar .................................................................................................................. 88
6.4.1.
6.4.1.1.
6.4.1.2.
Procedimiento de las pruebas ........................................................................................................ 89
6.4.2.
6.4.2.1.
6.4.2.2.
EDWEB-101 Pruebas de creación y edición de grafos ...........................................................................89
EDWEB-102 Pruebas de creación de estructuras de sitios Web ........................................................... 92
Resultados de las pruebas .............................................................................................................. 92
6.4.3.
CAPÍTULO 7.
7.1.
7.2.
7.3.
7.4.
Pruebas de creación y edición de grafos ............................................................................................... 88
Pruebas de creación de estructuras de sitios Web ...............................................................................89
CONCLUSIONES ..................................................................................................................102
CONCLUSIONES ...................................................................................................................................... 103
APORTACIONES ...................................................................................................................................... 103
TRABAJOS FUTUROS ................................................................................................................................ 103
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 iii
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 iv
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
Página v
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
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.
Página 2
Capítulo 1. Introducción
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:
Página 3
Capítulo 1. Introducción
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
Página 4
Capítulo 1. Introducción
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.).
Página 5
Capítulo 1. Introducción
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.
Página 6
Capítulo 1. Introducción
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.
Página 7
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
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].
Página 9
Capítulo 2. Marco teórico
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
Página 10
Capítulo 2. Marco teórico
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.
Página 11
Capítulo 2. Marco teórico
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.
Página 12
Capítulo 2. Marco teórico
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.
Página 13
Capítulo 2. Marco teórico
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]:
2.10.3.1.
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.
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.
Página 14
Capítulo 2. Marco teórico
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
Meronimia
Descripción
Canónica-Canónica2
Meronimia Facultativa-Facultativa3
Meronimia Facultativa-Canónica4
Meronimia Canónica-Facultativa5
Todo con parte obligatoria, parte obligatoria de
un todo.
Todo con parte opcional, parte opcional de un
todo.
Todo con parte opcional, parte obligatoria de un
todo.
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)
Meronimia F-F (en este documento)
4
Meronimia F-C (en este documento)
5
Meronimia C-F (en este documento)
3
Página 15
Capítulo 2. Marco teórico
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.
Agrupación con atributos comunes.
Agrupación de objetos inanimados.
Clase-Miembro
Colección-Miembro
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.
Página 16
Capítulo 2. Marco teórico
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
Página 17
Capítulo 2. Marco teórico
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.
Página 18
Capítulo 2. Marco teórico
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.
Página 19
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
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.
Página 21
Capítulo 3. Estado del arte
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:
8
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).
WebTOC sigue los enlaces o nombres de directorios para construir un árbol jerárquico del sitio.
Página 22
Capítulo 3. Estado del arte
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.
Página 23
Capítulo 3. Estado del arte
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.
Página 24
Capítulo 3. Estado del arte
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.
Página 25
Capítulo 3. Estado del arte
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.
Página 26
Capítulo 3. Estado del arte
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.
Página 27
Capítulo 3. Estado del arte
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
Página 28
Capítulo 3. Estado del arte
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/
Página 29
Capítulo 3. Estado del arte
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/
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.
14
Página 30
Capítulo 3. Estado del arte
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.
Página 31
Capítulo 3. Estado del arte
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.
Página 32
Capítulo 3. Estado del arte
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.
Página 33
Capítulo 3. Estado del arte
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.
Página 34
Capítulo 3. Estado del arte
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.
Página 35
Capítulo 3. Estado del arte
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.
Página 36
Capítulo 3. Estado del arte
Tabla 3.1. Comparación de herramientas del estado del arte
Característica
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
Dreamweaver
Si
Si
No
Si
No
No
No
SGMapper
UriGraph
CmapTools
Si
Si
Si
Si
No
Si
No
No
Si
No
No
No
No
No
No
Si
Si
No
No
Si
No
gOOWS
Si
No
No
No
No
No
Si
TouchGraph
Si
Si
No
No
No
Si
No
Personal Brain
Si
Si
No
No
No
No
No
OntoWebber
Si
No
No
No
No
Si
Si
Herramienta
propuesta
Si
Si
Si
Si
Si
Si
Si
Software de código
abierto
Software
propietario
No disponible
No disponible
Software de
distribución
gratuita con código
cerrado
Software de código
cerrado
Software con
versiones de código
abierto y cerrado
Software de
distribución
gratuita con código
cerrado
Software de código
abierto
Software de código
abierto
Herramienta
Página 37
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
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.
Página 39
Capítulo 4. Análisis y diseño de la solución
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.
No.
1
2
3
4
5
6
7
8
9
10
11
12
13
Tabla 4.1. Conjunto de sitios Web analizados
Nombre de la institución
Página
Centro de Investigación
Científica y de Educación
Superior de Ensenada
(CICESE)
Centro de Investigación en
Computación, IPN
Centro de Investigación en
Matemáticas, A. C.
Centro de Investigación y
Asistencia en Tecnología y
Diseño del estado de Jalisco
(CIATEJ)
Centro de Investigaciones
Biológicas del Noroeste, S. C.
(CIBNOR)
Centro de Investigación y de
Estudios Avanzados del
Instituto Politécnico Nacional
(CINVESTAV)
Centro de Investigación y
Docencia Económicas (CIDE)
Centro Nacional de
Investigación y Desarrollo
Tecnológico (CENIDET)
División Académica de
Economía, Derecho y Ciencias
Sociales, ITAM
Instituto Nacional de
Astrofísica, Óptica y
Electrónica (INAOE)
Instituto Tecnológico de
Acapulco (ITA)
Instituto Tecnológico de
Apizaco
Instituto Tecnológico del
Altiplano de Tlaxcala
Tipo de sitio
http://www.cicese.mx/
Centro de
Investigación
http://www.cic.ipn.mx/
Centro de
Investigación
http://www.cimat.mx/
http://www.ciatej.net.mx/
Centro de
Investigación
http://www.cibnor.mx/ecibnor.php
Centro de
Investigación
http://www.cinvestav.mx/
Centro de
investigación
http://www.cide.edu/
Centro de
investigación
Centro de
investigación
http://www.cenidet.edu.mx
http://daedcs.itam.mx/
Centro de
Investigación
http://www.inaoep.mx
Centro de
investigación
http://www.it-acapulco.edu.mx
Instituto
Tecnológico
Instituto
Tecnológico
Instituto
Tecnológico
http://www.itapizaco.edu.mx
http://italtiplanotlaxcala.edu.mx
Página 40
Capítulo 4. Análisis y diseño de la solución
14
15
16
17
18
19
20
Instituto Tecnológico de
Celaya (ITC)
Instituto Tecnológico de
Chihuahua
Instituto Tecnológico de
Chilpancingo
(ITCHILPANCINGO)
Instituto Tecnológico de
Ciudad Madero
Instituto Tecnológico de
Minatitlán (ITMINA)
Instituto Tecnológico de
Morelia
Laboratorio Nacional de
Informática Avanzada
(LANIA)
http://www.itc.mx/itc/scripts/index.
Php
http://www.itchihuahua.edu.mx/
http://www.itchilpancingo.edu.mx/
principal/servlet/hinicio
http://www. itcd.edu.mx/
http://www.itmina.edu.mx
http://www.itmorelia.edu.mx
http://www.lania.mx
Instituto
Tecnológico
Instituto
Tecnológico
Instituto
Tecnológico
Instituto
Tecnológico
Instituto
Tecnológico
Instituto
Tecnológico
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.
Página 41
Capítulo 4. Análisis y diseño de la solución
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.
Página 42
Capítulo 4. Análisis y diseño de la solución
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
Página 43
Capítulo 4. Análisis y diseño de la solución
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.
Página 44
Capítulo 4. Análisis y diseño de la solución
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.
class Class Model
Documento
+
+
+
Serv icio
Serv icio interno
Conectividad: char
Temporalidad: char
TipoEntidad: char
Información
Producto
Serv icio externo
Unidad
organizacional
Estructura
Descripción
Trámite
Organización
funcionamiento
Descripción
abstracta
Descripción
física
Suceso
Estudiante
Personal
Trabaj ador
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.
Página 45
Capítulo 4. Análisis y diseño de la solución
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.
Página 46
Capítulo 4. Análisis y diseño de la solución
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
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.
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
o
Temporal: una página con un periodo de vida determinado.
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
o
Espacio-material: con un nivel compositivo concreto.
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.
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Tabla 4.3. Definición de la clase Descripción abstracta
Descripción abstracta
Descripció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.
Presentación, misión, visión, objetivo, historia, ubicación, acerca de, servicios.
Tipo de entidad: simbólica.
Conectividad: simple/enlace.
Existencia: permanente.
Página 47
Capítulo 4. Análisis y diseño de la solución
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Tabla 4.4. Definición de la clase Descripción física
Descripción física
Descripción.
Elemento que muestra la disposición de los recursos de la institución.
Directorio, infraestructura, organigrama institucional.
Tipo de entidad: espacio-material.
Conectividad: simple/enlace.
Existencia: permanente.
Tabla 4.5. Definición de la clase Estudiante
Estudiante
Personal.
Contiene información sobre la persona que cursa estudios en una institución
educativa.
Estudiante de posgrado, estudiante de licenciatura.
Tipo de entidad: espacio-material.
Conectividad: simple.
Existencia: temporal.
Tabla 4.6. Definición de la clase Organización funcionamiento
Organización funcionamiento
Estructura.
Elemento que muestra la administración o coordinación de un proceso de
manera formal.
Reglamento, plan de estudios.
Tipo de entidad: simbólica.
Conectividad: simple.
Existencia: permanente.
Tabla 4.7. Definición de la clase Producto
Clase:
Producto
Superclase:
Definición:
Documento.
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.
Tesis, publicación.
Tipo de entidad: espacio-material.
Conectividad: simple.
Existencia: permanente.
Instancias:
Atributo:
Clase:
Tabla 4.8. Definición de la clase Servicio externo
Servicio externo
Superclase:
Definición:
Instancias:
Servicio.
Servicios ofrecidos por la institución a otras organizaciones.
Capacitación, consultoría, bolsa de trabajo.
Página 48
Capítulo 4. Análisis y diseño de la solución
Atributo:
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Tipo de entidad: simbólica.
Conectividad: simple.
Existencia: permanente.
Tabla 4.9. Definición de la clase Servicio interno
Servicio interno
Servicio.
Tipo de servicio que se ofrece al personal o estudiantes con respecto a la
institución.
Búsqueda, consulta bibliográfica, correo electrónico, kardex, centro de
idiomas.
Tipo de entidad: simbólica.
Conectividad: simple.
Existencia: permanente.
Tabla 4.10. Definición de la clase Suceso
Clase:
Suceso
Superclase:
Definición:
Información.
Acontecimiento relevante o actividad que posee carácter de importancia en
una temporada específica.
Noticia, evento, curso.
Tipo de entidad: simbólica.
Conectividad: simple.
Existencia: temporal.
Instancias:
Atributo:
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Tabla 4.11. Definición de la clase Trabajador
Trabajador
Personal.
Contiene información sobre la persona que labora en un organismo,
dependencia o institución.
Académico, administrativo.
Tipo de entidad: espacio-material.
Conectividad: simple.
Existencia: temporal.
Tabla 4.12. Definición de la clase Trámite
Clase:
Trámite
Superclase:
Definición:
Informació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.
Admisión, titulación, beca, servicio social, residencia profesional, actividad
extraescolar.
Tipo de entidad: simbólica.
Conectividad: simple.
Existencia: permanente.
Instancias:
Atributo:
Página 49
Capítulo 4. Análisis y diseño de la solución
Clase:
Superclase:
Definición:
Instancias:
Atributo:
Tabla 4.13. Definición de la clase Unidad organizacional
Unidad organizacional
Estructura.
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.
Departamento, línea de investigación, posgrado, principal, personas, bienes.
Tipo de entidad: simbólica.
Conectividad: enlace.
Existencia: permanente.
4.2.2.6. Establecimiento de relaciones de la ontología
class System
Léxica
Topológica
Léxica
paradigmática
Léxica
sintagmática
Meronimia
Produce
Hiperonimia
Registra
Meronimia
CanónicaCanónica
Meronimia E
Meronimia F
Meronimia
CanónicaFacultativ a
Meronimia G
Meronimia
Facultativ aCanónica
Meronimia
Facultativ aFacultativ a
Meronimia N
Meronimia A
Meronimia
ColecciónMiembro
Meronimia GrupoMiembro
Meronimia D
Meronimia C
Meronimia H
Meronimia I
Meronimia K
Meronimia L
Meronimia B
Meronimia M
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
Página 50
Capítulo 4. Análisis y diseño de la solución
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
Unidad organizacional
Unidad organizacional
Unidad organizacional
Organización funcionamiento
Descripción abstracta
Descripción física
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.
Página 51
Capítulo 4. Análisis y diseño de la solución
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
Unidad organizacional
Estudiante
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):
Página 52
Capítulo 4. Análisis y diseño de la solución
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):
Página 53
Capítulo 4. Análisis y diseño de la solución
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):
Página 54
Capítulo 4. Análisis y diseño de la solución
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):
Página 55
Capítulo 4. Análisis y diseño de la solución
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):
Página 56
Capítulo 4. Análisis y diseño de la solución
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):
Página 57
Capítulo 4. Análisis y diseño de la solución
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):
Dominio
Tabla 4.28. Dominio y rango para la relación Topológica
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):
Dominio
Trabajador
Tabla 4.29. Dominio y rango para la relación Produce
Rango
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.
Página 58
Capítulo 4. Análisis y diseño de la solució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.
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):
Dominio
Tabla 4.30. Dominio y rango para la relación Registra
Rango
DescripciónFísica
Trabajador
Página 59
Capítulo 4. Análisis y diseño de la solución
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
facultativafacultativa
0..1, 0..1
CascadaEnlace
Dinámico-Estático
Concepto compartido
(B) Meronimia
facultativafacultativa
(C) Meronimia
grupo-miembro
(D)Meronimia
colección-miembro
(E) Meronimia
canónica-canónica
(F) Meronimia
canónica-canónica
0..1, 0..*
CascadaEnlace
DinámicoDinámico
UnidadOrganizacionalOrganizaciónFuncionamiento
UnidadOrganizacionalDescripciónAbstracta
UnidadOrganizacionalDescripciónFísica
UnidadOrganizacionalUnidadOrganizacional
DescripciónAbstractaOrganizaciónFuncionamiento
1,*
RestringidoEnlace
RestringidoEnlace
CascadaCascada
CascadaEnlace
Dinámico-Estático
UnidadOrganizacional-Estudiante
UnidadOrganizacional-Trabajador
UnidadOrganizacional-Producto
Parte exclusiva
Dependencia existencial
(G) Meronimia
canónica-canónica
(H) Meronimia
canónica-canónica
(I) Meronimia
canónica-canónica
(J) Meronimia
canónica-canónica
1, 1..*
RestringidoEnlace
CascadaEnlace
CascadaEnlace
CascadaEnlace
DinámicoDinámico
Estático-Estático
UnidadOrganizacionalOrganizaciónFuncionamieto
UnidadOrganizacionalUnidadOrganizacional
DescripciónAbstractaServicioInterno
DescripciónAbstractaServicioExterno
UnidadOrganizacionalDescripciónFísica
UnidadOrganizacionalDescripciónAbstracta
UnidadOrganizacionalUnidadOrganizacional
UnidadOrganizacionalDescripciónAbstracta
1, 1..*
1,1
1, 1..*
1,1
1, 0..*
1,1
Dinámico-Estático
Estático-Estático
Dinámico-Estático
Dinámico-Estático
Estático-Estático
Concepto compartido
Parte obligatoria
Parte obligatoria
Todo obligatorio
Parte obligatoria
Parte exclusiva
Parte obligatoria
Página 60
Capítulo 4. Análisis y diseño de la solución
(K) Meronimia
canónicafacultativa
(L) Meronimia
canónicafacultativa
(M)Meronimia
canónicafacultativa
(N) Meronimia
facultativacanónica
Topológica
0..1, 1..*
CascadaEnlace
Estático-Estático
DescripciónAbstractaDescripciónAbstracta
Parte obligatoria
0..1, 1
CascadaEnlace
Estático-Estático
DescripciónAbstractaDescripciónFísica
Parte obligatoria
0..1, 1..*
CascadaEnlace
Dinámico-Estático
DescripciónFísicaUnidadOrganizacional
Parte obligatoria
1, 0..*
CascadaEnlace
Dinámico-Estático
UnidadOrganizacional-Trámite
Parte exclusiva
1, 0..*
Ninguna
1, 0..*
DinámicoDinámico
Dinámico-Estático
UnidadOrganizacional-Suceso
Registra
Trabajador-DescripciónFísica
Ninguna
Produce
1..*, 1..*
CascadaEnlace
EnlaceEnlace
EnlaceEnlace
Dinámico-Estático
Estudiante-Producto
Trabajador-Producto
Ninguna
Página 61
Capítulo 4. Análisis y diseño de la solución
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.
class Domain Obj ects
Usuario
Salida
Entrada
Buscar XML
Archiv os
Retorna XML
XML a verificar
Editor manual de
grafos
XML a interpretar
XML verificado
Verificador
XML para creación de estructura
Grafo del XML
Panel de
v isualización de
grafos
Generador de
estructura
Archivos para almacenamiento
Figura 4.6. Arquitectura general del editor EDWEB
Página 62
Capítulo 4. Análisis y diseño de la solución
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.
Página 63
Capítulo 4. Análisis y diseño de la solución
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.
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.
18
Página 64
Capítulo 4. Análisis y diseño de la solución
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.
ID:
Actores:
Descripción:
Precondiciones:
Poscondiciones:
Escenario de éxito 1:
Tabla 4.32. Propiedades de CU-1 Crear grafo del sitio Web
CU-1
Crear grafo del sitio Web
Constructor del sitio Web.
Permite al usuario crear un nuevo grafo en el panel de edición.
1. Debe cargarse la ontología requerida en la aplicación
1. Se obtiene un grafo con nodos y aristas etiquetadas
1. Se abre la aplicación
2. Se carga la ontología requerida
Página 65
Capítulo 4. Análisis y diseño de la solución
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
Supone que la ontología para esta aplicación ha sido creada.
Suposición:
ID:
Tabla 4.33. Propiedades de CU-2 Crear archivo XML a partir de un grafo
CU-2
Crear archivo XML a partir de un grafo
Actores:
Descripción:
Precondiciones:
Poscondiciones:
Escenario de éxito 1:
Escenario de éxito 2:
Suposición:
ID:
Constructor del sitio Web.
Permite al usuario generar el archivo descriptivo de la estructura de un
sitio Web a partir de un grafo.
1. Debe existir un grafo creado previamente
2. Todos los nodos y aristas del grafo deben estar etiquetados
1. Se almacena un archivo XML con una sección descriptiva para nodos y
otra para aristas
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
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
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
CU-3
Generar grafo a partir de un archivo XML
Actores:
Descripción:
Precondiciones:
Poscondiciones:
Escenario de éxito 1:
Suposición:
ID:
Actores:
Descripción:
Precondiciones:
Poscondiciones:
Constructor del sitio Web.
Permite al usuario visualizar un grafo a partir de un archivo XML que se
ha creado con anterioridad.
1. Debe existir un archivo XML guardado
2. El grafo creado en el panel debe mostrar los nodos y aristas que no están
etiquetados.
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.
El archivo XML utilizado mantiene la estructura del DTD.
Tabla 4.35. Propiedades de CU-4 Generar estructura del sitio Web
CU-4
Generar estructura del sitio Web
Constructor del sitio Web.
Permite al usuario crear un conjunto de páginas basadas en un grafo
diseñado en la herramienta editor.
1. Debe crearse y guardarse un archivo XML previamente
2. El archivo XML debe ser verificado para validar sus consistencia
1. Las páginas creadas deben contener los enlaces correspondientes hacia
Página 66
Capítulo 4. Análisis y diseño de la solución
Escenario de éxito 1:
Escenario de éxito 2:
Escenario de fracaso
1:
Suposición:
Tabla 4.36. Propiedades de CU-5 Crear reporte de errores
CU-5
Crear reporte de errores
ID:
Actores:
Descripción:
Precondiciones:
Poscondiciones:
Escenario de éxito 1:
Escenario de éxito 2:
Suposición:
ID:
Actores:
Descripción:
Precondiciones:
Poscondiciones:
otras páginas
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
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
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
La carpeta no existe o si existe se desea realizar cambios en ella y es posible
sobreescribirla.
Constructor del sitio Web.
Proporcionar al usuario un elemento que le permita listar la serie de
errores encontrados en el grafo.
1. Debe existir un grafo creado previamente
1. El reporte generado indica los nodos origen y destino de la arista
indefinida
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
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
El archivo XML existe.
Tabla 4.37. Propiedades de CU-6 Validar estructura del sitio Web
CU-6
Validar estructura del sitio Web
Constructor del sitio Web.
La validación ayuda al usuario a detectar posibles inconsistencias en el
grafo creado.
1. El grafo está siendo modificado
2. El grafo ha sido previamente guardado
1. Se indica en el grafo, con un cambio de color, las aristas o nodos
etiquetados incorrectamente
Página 67
Capítulo 4. Análisis y diseño de la solución
Escenario de éxito 1:
Escenario de éxito 2:
Suposición:
2. Se indica la falta de etiquetas en los nodos
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
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
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.
Página 68
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
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.
Página 70
Capítulo 5. Implementación
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.
Página 71
Capítulo 5. Implementación
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.
Página 72
Capítulo 5. Implementación
class client
JPanel
TGLinkBrow ser
+
+
+
~
~
~
+
~
#
#
+
+
+
~
~
~
+
~
~
~
~
~
~
~
~
+
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
-parser
-
file: File = null
model: OntModel = null
+
+
+
+
getIndividuals() : List<Individual>
getInfModel() : InfModel
getOntClass() : List<OntClass>
JenaParser(File)
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.
Página 73
Capítulo 5. Implementación
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.
Página 74
Capítulo 5. Implementación
class client
+from
~dragNode
+
+
+
+
+
#
+
+
+
+
+
+
#
#
#
#
#
+
#
+
+
#
#
+
+
+
#
#
+
+
+
#
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
JPanel
Runnable
GraphEltSet
Node
LBEdge
Edge
TGLayout
+tgLayout
~
# col: Color
- damper: double
+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}
+
AUTO_ID_STRING: String = "AutoID " {readOnly}
+ DEFAULT_COLOR: Color = Color.decode("#...
- damping: boolean
+ DEFAULT_TYPE: int = 1
#
BACK_DEFAULT_COLOR: Color = new Color(208, ...
+ DEFAULT_LENGTH: int = 350
~ dragNode: Node
+ edgeType: int
~
BACK_FIXED_COLOR: Color
+ from: Node
- lastMaxMotion: double
+ HIERARCHICAL_EDGE: int = 1 {readOnly}
BACK_HILIGHT_COLOR: Color = Color.decode("#...
# length: int
- maxMotion: double
label:
String
~
+ addEdge(Edge) : void
BACK_SELECT_COLOR: Color = new Color(255, ...
+ MOUSE_OVER_COLOR: Color
- motionRatio: double
+
LABEL_BACK_COLOR:
Color
=
new
Color(255,
...
+ addEdge(Node, Node, int) : Edge
-tgPanel backColor: Color
+ to: Node
- newRigidity: double
+ LABEL_FONT: Font = new Font("Couri...
+ addNode(Node) : void
BORDER_DRAG_COLOR: Color
~completeEltSet
# visible: boolean
- relaxer: Thread
+ LABEL_TEXT_COLOR: Color
#
+ calculateDistances(Node, int) : Hashtable
BORDER_INACTIVE_COLOR: Color
- rigidity: double
#
+ clearAll() : void
BORDER_MOUSE_OVER_COLOR: Color = new Color(160, ...
+ containsPoint(double, double) : boolean
- tgPanel: TGPanel
+ getLabel() : String
#
+ contains(Node) : boolean
DEFAULT_TYPE: int = 1
+ distFromPoint(double, double) : double
+ getType() : int
#
+ contains(Edge) : boolean
drawx: double
+ Edge(Node, Node, int)
- avoidLabels() : void
+ LBEdge(LBNode, LBNode)
+ deleteEdge(Edge) : boolean
drawy: double
+ Edge(Node, Node)
+ damp() : void
+ LBEdge(LBNode, LBNode, int)
~
+ deleteEdge(Node, Node) : boolean
dx: double
+ getColor() : Color
- moveNodes() : void
+ paint(Graphics, int, int, int, int, Color, int) : void
~
+
deleteEdges(Vector)
:
void
dy: double
+ getFrom() : Node
- myWait() : void
+
paint(Graphics,
TGPanel)
:
void
~
+ deleteNode(Node) : boolean
edges: Vector
+ getLength() : int
- relax() : void
+
paintEdgeBody(Graphics,
TGPanel)
:
void
+ deleteNodes(Vector) : void
fixed: boolean
+ getOtherEndpt(Node) : Node
- relaxEdges() : void
+
paintFatLine(Graphics,
int,
int,
int,
int,
Color)
:
void
#
# edgeAt(int) : Edge
font: Font
+ getTo() : Node
+ resetDamper() : void
+ setEdgeDafaultType(int) : void
~
+ edgeNum() : int
fontMetrics: FontMetrics
+ intersects(Dimension) : boolean
+ run() : void
+ setLabel(String) : void
+
+ findEdge(Node, Node) : Edge
id: String
+ isVisible() : boolean
~ setDragNode(Node) : void
+ setType(int) : void
~
+ findNode(String) : Node
justMadeLocal: boolean
+ paint(Graphics, TGPanel) : void
~ setRigidity(double) : void
~
+ findNodesByLabel(String) : Collection
lbl: String
+ paintArrow(Graphics, int, int, int, int, Color) : void
+ start() : void
+ forAllEdges(TGForEachEdge) : void
localEdgeCount: int
+ reverse() : void
+ startDamper() : void
+ forAllNodePairs(TGForEachNodePair) : void
markedForRemoval: boolean
+ setColor(Color) : void
+ stop() : void
+
+ forAllNodes(TGForEachNode) : void
nm: String
+ setEdgeDefaultColor(Color) : void
+ stopDamper() : void
+
+
getFirstNode()
:
Node
repulsion: int
+ setEdgeDefaultLength(int) : void
+ TGLayout(TGPanel)
+
+ getRandomNode() : Node
SMALL_TAG_FONT: Font = new Font("Couri... {readOnly}
+ setEdgeMouseOverColor(Color) : void
+
+ GraphEltSet()
TEXT_COLOR: Color
+ setLength(int) : void
#mouseOverE
+
# nodeAt(int) : Node
TEXT_FONT: Font = new Font("Couri...
+ setVisible(boolean) : void
-completeEltSet
+
+ nodeNum() : int
textColor: Color
+
typ: int
+
TYPE_ELLIPSE: int = 3 {readOnly}
+
TYPE_RECTANGLE: int = 1 {readOnly}
#select
+
TYPE_ROUNDRECT: int = 2 {readOnly}
~dragNode
+
visible: boolean
#mouseOverN
+
x: double
~tgPanel
+
y: double
JInternalFrame
+
LBNodeDialog
+
addEdge(Edge) : void
+to
+
containsPoint(double, double) : boolean
- cbHintIsHTML: JCheckBox
+
containsPoint(Point) : boolean
- cbLocal: JCheckBox
JPanel
#
edgeAt(int) : Edge
- cboFontSize: JComboBox
+
TGLinkBrow ser
edgeNum() : int
- cboNodeType: JComboBox
~
getBackColor() : Color
- cbXML: JCheckBox
+ arbolNodos: JTree
+
getFixed() : boolean
- cmdCancel: JButton
+ band: int = 0
+
getFont() : Font
- cmdOK: JButton
+ bar: JScrollPane
+
getHeight() : int
- lastBackColorButton: JButton
~ completeEltSet: GraphEltSet = null
+
getID() : String
- lastTextColorButton: JButton
- documentBase: URL
+
getLabel() : String
- lblBackColor: JLabel
~tgPanel +
- enclosingApplet: JApplet = null
LBNode
getLocation() : Point
- lblTextColor: JLabel
- enclosingFrame: JFrame = null
+
getName() : String
~ hint: String
~ lbNode: LBNode
~ externalFrame: String
+
getPaintBackColor(TGPanel) : Color
+ HINT_BACK_COLOR: Color
- taHint: JTextArea
~ graphsVisited: Stack = new Stack() {readOnly}
+
getPaintBorderColor(TGPanel) : Color
+ HINT_FONT: Font = new Font("Couri...
- tfBackColor: JTextField
+ hvScroll: HVScroll
+
getPaintTextColor(TGPanel) : Color
+ HINT_TEXT_COLOR: Color
- tfHintHeight: JTextField
~ initialNodeName: String
+
getTextColor() : Color
~ hintFont: Font
- tfHintWidth: JTextField
# lbEdgeDialog: LBEdgeDialog
+
getType() : int
~ hintHeight: int
- tfLabel: JTextField
# lbNodeDialog: LBNodeDialog
+
getWidth() : int
~ hintIsHTML: boolean
- tfTextColor: JTextField
+ lbPopup: JPopupMenu
+
initialize(String) : void
~ hintWidth: int
- tfURL: JTextField
+ listReport: JList
+
intersects(Dimension) : boolean
+ MINIMUM_HINT_HEIGHT: int = 20
~ tgPanel: TGPanel
+ localityScroll: LocalityScroll
+
isVisible() : boolean
~ url: String
~ modeSelectPanel: JPanel
+
localEdgeNum() : int
~ urlIsLocal: boolean
- encodeColor(Color) : String
~
openFile:
JButton
=
new
JButton()
+
~lbNode
Node()
~ urlIsXML: boolean
- initColorSelectors() : void
- parser: JenaParser = null
+
Node(String)
- initComponents() : void
~ proxyServlet: String
~
Node(String, String)
+ getHeight() : int
+ LBNodeDialog(TGPanel)
+ rotateScroll: RotateScroll
+
Node(String, int, Color, String)
+ getHint() : String
+ main(String[]) : void
~ scrollBarHash: Hashtable = new Hashtable() {readOnly}
+
paint(Graphics, TGPanel) : void
+ getHintHeight() : int
+ saveChangesAndHideDialog() : void #lbNodeDialog
~ targetFrame: String
+
paintNodeBody(Graphics, TGPanel) : void
+ getHintIsHTML() : boolean
- setBackColor(Color) : void
~ textOntology: JTextField = new JTextField()
paintSmallTag(Graphics, TGPanel, int, int, Color, Color, char) : void
+ getHintWidth() : int
+ setLBNode(LBNode) : void
~ tgLensSet: TGLensSet
+
removeEdge(Edge) : void
+ getPaintBackColor(TGPanel) : Color
- setTextColor(Color) : void
~
tgPanel:
TGPanel
+
setBackColor(Color) : void
+ getPaintBorderColor(TGPanel) : Color
+ showDialog() : void
~ tgUIManager: TGUIManager
+
setFixed(boolean) : void
+ getPaintTextColor(TGPanel) : Color
~ xmlFileName: String
+
setFont(Font) : void
+ getPaintUnselectedBackColor() : Color
~ xmlio: XMLio
+
setID(String) : void
+ getURL() : String
+ zoomScroll: ZoomScroll
+
setLabel(String) : void
TGAbstractDragUI
+ getURLIsLocal() : boolean
+
setLocation(Point) : void
LBDragAddNodeUI
+ getURLIsXML() : boolean
+ addElement(Vector) : void
+
setName(String) : void
+ getWidth() : int
- addUIs() : void
+
setNodeBackDefaultColor(Color) : void
~ cboParRel: JComboBox
+ LBNode()
- buildLens() : void
+
setNodeBackFixedColor(Color) : void
~ dragAddNode: LBNode
+ LBNode(String)
- buildPanel() : void
+
setNodeBackHilightColor(Color) : void
~
mousePos:
Point
+ LBNode(String, String, String)
- createParameterHash() : Hashtable
+
setNodeBackSelectColor(Color) : void
~ newNode: String = "UnidadOrganiza...
~ myBrighter(Color) : Color
+ getDocumentBase() : URL
+
setNodeBorderDragColor(Color) : void
~ result: Boolean
+ paint(Graphics, TGPanel) : void
+ getTGPanel() : TGPanel
~
setNodeBorderInactiveColor(Color) : void
~ tgLinkBrowser: TGLinkBrowser
+ separatorString(String) : String
jbInit()
:
void
+
~tgLinkBrowser
setNodeBorderMouseOverColor(Color) : void
+ setHint(String) : void
~dragAddNode
- lblMenuBarPrincipal() : JMenuBar
+
setNodeTextColor(Color) : void
+ LBDragAddNodeUI(TGLinkBrowser)
+ setHintHeight(int) : void
+ main(String[]) : void
+
setNodeTextFont(Font) : void
+ mouseDragged(MouseEvent) : void
+ setHintIsHTML(boolean) : void
~ processNodeUrl(LBNode) : void
+
setNodeType(int) : void
+ mousePressed(MouseEvent) : void
+ setHintWidth(int) : void
- restoreSavedParameters(Hashtable) : void
+
setTextColor(Color) : void
+ mouseReleased(MouseEvent) : void
+ setNodeHintBackColor(Color) : void
~ salir_ActionPerformed(ActionEvent) : void
+
setType(int) : void
+ paintAfterEdges(Graphics) : void
+ setNodeHintFont(Font) : void
~ scrollSelectPanel(String[]) : JPanel
+
setVisible(boolean) : void
+ paintFirst(Graphics) : void
+ setNodeHintTextColor(Color) : void
+ setLocale(String, int) : void
+
+ paintLast(Graphics) : void
+ setURL(String) : void
+ TGLinkBrowser()
+
+ preActivate() : void
+ setURLIsLocal(boolean) : void
+ TGLinkBrowser(JApplet)
+
+ preDeactivate() : void
+ setURLIsXML(boolean) : void
~ TGLinkBrowser(JFrame)
+
+ returnData() : String
+ titles(String, int, int, int, int) : JLabel
+
#
+
#
#
edges: Vector
nodeCount: int
nodeIDRegistry: Hashtable = null
nodes: Vector
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
updateLocalityFromVisibility() : void
updatePosFromDraw(Node) : void
Figura 5.5. Clases para la creación de grafos
Página 75
Capítulo 5. Implementación
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
Página 76
Capítulo 5. Implementación
class client
~tgPanel
JPanel
JPanel
~
~
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)
~graphEltSet
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 -completeEltSet
forAllNodes(TGForEachNode) : void
getFirstNode() : Node
getRandomNode() : Node
GraphEltSet()
nodeAt(int) : Node
nodeNum() : int
~completeEltSet
TGPanel
TGLinkBrow ser
~xmlio
XMLio
+
+
+
~
~
~
+
~
#
#
+
+
+
~
~
~
+
~
~
~
~
~
~
~
~
+
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
~
+
#
~
~
#
#
#
#
~
~
~
#
~
+
~
~
-
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
updateLocalityFromVisibility() : void
updatePosFromDraw(Node) : void
Node
#select
+
#mouseOverN +
+
~dragNode +
+
#
+
+
+
+
+from +
+
#
#
#
#
#
+to +
#
+
+
#
#
+
+
+
#
#
+
+
+
#
+
+
Edge
#
+
+
+
#
+
+
#
+
+
+
#mouseOverE +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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
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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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
Figura 5.7. Diagrama de clases para la creación de un archivo XML
Página 77
Capítulo 5. Implementación
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.
class client
JPanel
TGLinkBrow ser
+
+
+
~
~
~
+
~
#
#
+
+
+
~
~
~
+
~
~
~
~
~
~
~
~
+
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
~
~
+
~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)
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.
Página 78
Capítulo 5. Implementación
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
Página 79
Capítulo 5. Implementación
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.
Página 80
Capítulo 5. Implementación
class client
#mouseOverN
JPanel
TGPanel
ParserHTML
~
~
~
graphEltSet: GraphEltSet
parameterHash: Hashtable
v: Vector
+
+
buildPages(IXMLElement) : void
ParserHTML()
read(String, InputStream) : void
+from
~
+
#
~
~
#
#
#
#
~
~
~
#
~
+
~
~
-
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
- encodeColor(Color) : String
deleteEdge(Node, Node) : void
- initColorSelectors() : void
deleteNode(Node) : boolean
- initComponents() : void
deleteNodeById(String) : boolean
+ LBNodeDialog(TGPanel)
edgeNum() : int
+ main(String[]) : void
expandNode(Node) : void
+ saveChangesAndHideDialog() : void
findEdge(Node, Node) : Edge
- setBackColor(Color) : void
findMouseOver() : void
+ setLBNode(LBNode) : void
findNode(String) : Node
- setTextColor(Color) : void
fireMovedEvent() : void
+
+ showDialog() : void
fireResetEvent() : void
+
#lbNodeDialog
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
+
~tgPanel
getTopLeftDraw() : TGPoint2D
+
~graphEltSet
hideEdge(Edge) : void
~
hideNode(Node, Node) : void
~
main(String[]) : void
GraphEltSet
multiSelect(TGPoint2D, TGPoint2D) : void
~
# edges: Vector
myBrihgter(Color) : Color
+
+ nodeCount: int
nodeNum() : int
~
# nodeIDRegistry: Hashtable = null
paint(Graphics) : void
~
# nodes: Vector
processGraphMove() : void
~
redraw() : void
~
+
addEdge(Edge)
:
void
removeGraphListener(GraphListener) : void
~
+
addEdge(Node,
Node,
int)
:
Edge
removePaintListener(TGPaintListener) : void
~
+ addNode(Node) : void
repaintAfterMove() : void
~
+ calculateDistances(Node, int) : Hashtable
resetDamper() : void
~
+ clearAll() : void
selectFirstNode() : void
+
+ contains(Node) : boolean
setBackColor(Color) : void
+
contains(Edge)
:
boolean
setDragNode(Node) : void
+
+
deleteEdge(Edge)
:
boolean
setGraphEltSet(GraphEltSet) : void
~completeEltSet
-completeEltSet + deleteEdge(Node, Node) : boolean
setLensSet(TGLensSet) : void
+ deleteEdges(Vector) : void
setLocale(Node, int) : void
+ deleteNode(Node) : boolean
setMaintainMouseOver(boolean) : void
+ deleteNodes(Vector) : void
setMouseOverE(Edge) : void
+
# edgeAt(int) : Edge
setMouseOverN(Node) : void
+
+
edgeNum()
:
int
setMousePos(Point) : void
+
findEdge(Node,
Node)
:
Edge
setNombreNodo(String) : void
+
findNode(String)
:
Node
setSelect(Node) : void
+
+ findNodesByLabel(String) : Collection
setTGLayout(TGLayout) : void
~
+ forAllEdges(TGForEachEdge) : void
startDamper() : void
+ forAllNodePairs(TGForEachNodePair) : void
stopDamper() : void
~
+ forAllNodes(TGForEachNode) : void
TGPanel()
~
+
getFirstNode()
:
Node
update(Graphics) : void
+
+
getRandomNode()
:
Node
updateDrawPos(Node) : void
+
+
GraphEltSet()
updateDrawPositions() : void
+
# nodeAt(int) : Node
updateGraphSize() : void
~
+ nodeNum() : int
updateLocalityFromVisibility() : void
+
Edge
#
+
+
+
#
#mouseOverE
+
+
#
JInternalFrame
LBNodeDialog
~tgPanel
~
~
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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
col: Color
DEFAULT_COLOR: Color = Color.decode("#...
DEFAULT_LENGTH: int = 350
from: Node
length: int
MOUSE_OVER_COLOR: Color
to: Node
visible: boolean
LBNode
~
+
+
+
~
~
~
~
+
~
~
~
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
JPanel
TGLinkBrow ser
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
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
+
+
+
+
+
+
+
+
+
+
~lbNode
+
+
+
+
+
+
~
+
+
+
+
+
+
+
+
+
+
+
+
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
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
TGForEachNode
+
+
forEachNode(Node) : void
TGForEachNode()
TGForEachEdge
+
+
Node
+
+
+to +
+
+
#
+
+
+
+
+
+
#
#
#
#
#
+
#
+
+
#
#
+
+
+
#
#
+
+
+
#
+
+
forEachEdge(Edge) : void
TGForEachEdge()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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
~dragNode
#select
updatePosFromDraw(Node) : void
Figura 5.11. Diagrama de clases para la generación de estructuras de sitios Web
Página 81
Capítulo 5. Implementación
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.
class client
Edge
JPanel
+
+
+
~
~
~
+
~
#
#
+
+
+
~
~
~
+
~
~
~
~
~
~
~
~
+
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
LBEdge
TGLinkBrow ser
+
+
+
+
+
+
+
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
~newEdge
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)
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
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.
Página 82
Capítulo 5. Implementación
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.
Página 83
Capítulo 5. Implementación
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.
class client
JPanel
JInternalFrame
TGLinkBrow ser
LBEdgeDialog
+
+
+
~
~
~
+
~
#
#
+
+
+
~
~
~
+
~
~
~
~
~
~
~
~
+
arbolNodos: JTree
band: int = 0
bar: JScrollPane
completeEltSet: GraphEltSet = null
documentBase: URL
enclosingApplet: JApplet = null
enclosingFrame: JFrame = null
externalFrame: String
#lbEdgeDialog
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}
~tgLinkBrowser
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
~
~
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
MouseMotionAdapter
LBEditUI::LBEditMouseMotionListener
~
+
LBEditMouseMotionListener()
mouseMoved(MouseEvent) : void
~mml
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
XMLio
~
~
~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
MouseAdapter
LBEditUI::LBEditMouseListener
~
+
+
+
LBEditMouseListener()
mouseClicked(MouseEvent) : void
mousePressed(MouseEvent) : void
mouseReleased(MouseEvent) : void
Figura 5.15. Diagrama de clases para la validación de estructuras de sitios Web
Página 84
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
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
Página 86
Capítulo 6. Pruebas
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
Clasificación de ejemplares con las clases proporcionadas
Compresión de la información sobre las relaciones
Etiquetado de enlaces con las relaciones propuestas
Facilidad de estructuración
Comprensión de la estructura etiquetada
P
P
P
E
E
E
P
P
P
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
P
P
E
E
E
E
E
P
E
E
E
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:
Página 87
Capítulo 6. Pruebas
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.
Página 88
Capítulo 6. Pruebas
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.
Página 89
Capítulo 6. Pruebas
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.
Página 90
Capítulo 6. Pruebas
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.
Página 91
Capítulo 6. Pruebas
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.
Página 92
Capítulo 6. Pruebas
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.
Página 93
Capítulo 6. Pruebas
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
Clase
Ejemplar
Relación
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ú
Guardar grafo
Página 94
Capítulo 6. Pruebas
Archivo a guardar
Nombre del archivo
Archivo XML generado
Página 95
Capítulo 6. Pruebas
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ú
Abrir grafo existente
Archivo a graficar
Archivo
Grafo generado a partir del archivo
Grafo
Página 96
Capítulo 6. Pruebas
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
Grafo
Reporte de tripletas indefinidas
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.
Página 97
Capítulo 6. Pruebas
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
Página 98
Capítulo 6. Pruebas
Nodo con etiqueta
Valor
indefinido
para el nodo
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
Página 99
Capítulo 6. Pruebas
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.
Página 100
Capítulo 6. Pruebas
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
EDWEB-101-004
UnidadOrganizacional:
Departamento CC
DescripciónAbstracta:
Presentación
UnidadOrganizacional:
Departamento CC
UnidadOrganizacional:
Departamento CC
UnidadOrganizacional:
Departamento CC
UnidadOrganizacional: Principal
UnidadOrganizacional: Sistemas
Distribuidos
DescripciónFísica: Infraestructura
(F) Meronimia
canónica-canónica
(A) Meronimia
facultativafacultativa
(I) Meronimia
canónica-canónica
(G) Meronimia
canónica-canónica
(I) Meronimia
canónica-canónica
Indefinida
EDWEB-101-005
EDWEB-101-006
EDWEB-102-001
OrganizaciónFuncionamiento:
Departamento de CC
OrganizaciónFuncionamiento:
Departamento de CC
UnidadOrganizacional:
SistemasDistribuidos
UnidadOrganizacional:
SistemasDistribuidos
UnidadOrganizacional: Posgrado
UnidadOrganizacional:
PersonalAcadémico
OrganizaciónFuncionamiento:
Departamento de CC
Trabajador: Dr. Juan Gabriel
Indefinida
Trabajador: Dr. José Antonio
Indefinida
UnidadOrganizacional: Posgrado
(F) Meronimia
canónica-canónica
(I) Meronimia
canónica-canónica
(E) Meronimia
canónica-canónica
(D) Meronimia
colección-miembro
Indefinida
UnidadOrganizacional:
Publicaciones
OrganizaciónFuncionamiento:
Plan de estudios
Producto: Artículo
UnidadOrganizacional:
Publicaciones
UnidadOrganizacional: Sistemas UnidadOrganizacional: Posgrado
Distribuidos
UnidadOrganizacional: Sistemas Servicio: *
Distribuidos
Grafo del caso EDWEB-101-004
Indefinida
Nota: * denomina un nodo sin nombre de ejemplar definido.
Página 101
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
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
Página 103
Capítulo 6. Conclusiones
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 104
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
Unidad
organizacional
Unidad
organizacional
Unidad
organizacional
Descripción
abstracta
Ingeniería
Mecánica
Ingeniería
Mecatrónica
Ingeniería
Electrónica
Ciencias
Computacionales
Presentación
(F) Meronimia
canónica-canónica
(F) Meronimia
canónica-canónica
(F) Meronimia
canónica-canónica
(F) Meronimia
canónica-canónica
(K) Meronimia
canónicafacultativa
(A) Meronimia
facultativafacultativa
(A) Meronimia
facultativafacultativa
Topológica
Unidad
organizacional
Unidad
organizacional
Unidad
organizacional
Unidad
organizacional
Unidad
organizacional
Cenidet
Unidad
organizacional
Cenidet
Descripción
física
Directorio
Unidad
organizacional
Cenidet
Descripción
física
Localización y
traslado
Unidad
organizacional
Cenidet
Suceso
Curso de
actualización
Cenidet
Cenidet
Cenidet
Cenidet
Página 105
A.2 Fragmento de grafo del departamento de Física del CINVESTAV
Dominio
Nodo del
dominio
Rango
Nodo del rango
Unidad
organizacional
Departamento
de Física
Unidad
organizacional
Programa de
maestría en
ciencias (Física)
Principal
Unidad
organizacional
Departamento
de Física
Descripción
abstracta
Unidad
organizacional
Departamento
de Física
Descripción
física
Directorio
Unidad
organizacional
Departamento
de Física
Descripción
física
Ubicación
Unidad
organizacional
Unidad
organizacional
Unidad
organizacional
Departamento
de Física
Investigadores
Unidad
organizacional
Trabajador
Investigadores
Investigadores
Trabajador
Baquero Parra,
Rafael
Bretón Báez, Nora
Eva
Relación
(A) Meronimia
facultativafacultativa
A) Meronimia
facultativafacultativa
A) Meronimia
facultativafacultativa
A) Meronimia
facultativafacultativa
(I) Meronimia
canónica-canónica
(C) Meronimia
grupo-miembro
(C) Meronimia
grupo-miembro
Página 106
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 107
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 108
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 109
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 110
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 111
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 112
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 113
"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 114
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 115
Referencias
[ADOBE 07]
[BRAIN 04]
[BRAIN 07]
[CAÑAS 03]
[COOLEY 00]
[CRUSE 86]
[DÍEZ 99]
[FONS 02]
[GUIZZARDI 05]
[GREENWICH 07]
[GRUBER 93]
[HASSAN 03]
[IHCM 07]
[INSFRÁN 98]
[JIN 01]
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”.
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”.
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 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 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 D. A; “Lexical Semantics”; Cambridge University Press; 1986.
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 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 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.
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 T.; “A Translation Approach to Portable Ontology Specifications”;
Knowledge Acquisition 5(2); ISSN: 1042-8143; pp. 199-220, 1993.
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”.
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 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 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 116
[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 117
[USCHOLD 96]
[W3C 08]
[W3C 08b]
Uschold M., Gruninger M.; 1996; “Ontologies: principles, methods and
applications”; Knowledge Engineering Review 11; No. 2; pp 320-321.
W3C. Semantic Web; [En línea]; [Accedido el 27 de marzo de 2008]; Disponible
en: “http://www.w3.org/2001/sw/”.
Extensible Markup Language; [En línea]; [Accedido el 27 de junio del 2008];
Disponible en: “http://www.w3.org/XML/”.
Página 118
