centro nacional de investigación y desarrollo tecnológico20matilde%… · resumen los sitios web...

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Metodología para Definir una Arquitectura de Sitios Web Basada en Diseño de Ontologías

presentada por

Matilde Baños Nolasco Ing. en Sistemas Computacionales por el I. T. de Minatitlán

como requisito para la obtención del grado de:

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

Director de tesis: Dr. José Antonio Zárate Marceleño

Co-Director de tesis:

Dr. Juan Gabriel González Serna

Jurado: M.C. Mario Guillén Rodríguez – Presidente

Dr. José Antonio Zárate Marceleño– Secretario M.C. Reynaldo Alanís Cantú – Vocal

M.C. Hugo Estrada Esquivel – Vocal Suplente

Cuernavaca, Morelos, México. 11 de septiembre de 2008

“Hay hombres que luchan un día y son buenos. Hay otros que luchan un año y son mejores.

Hay quienes luchan muchos años, y son muy buenos. Pero hay los que luchan toda la vida, esos son los imprescindibles.”

Bertolt Brecht

Dedicatoria

A mis padres: A mi padre. Por enseñarme que nada en la vida es fácil de alcanzar, pero que el trabajo duro siempre recibe recompensa. De usted aprendí que es importante ser estricto y justo, sin dejar de ser flexible. Que se debe mantener la dignidad a toda costa y que nunca se debe negar la

mano a quien la extiende buscando ayuda. Aunque no está físicamente, estará siempre en mi corazón y en cada logro de mi vida.

A mi madre. Gracias por tu fortaleza y tu entereza a lo largo de los años. Por los enormes

sacrificios con los que has sacado adelante a nuestra familia. Por demostrarme que ni siquiera los impedimentos físicos son un pretexto para dejarse vencer y que no existe sentimiento que

engrandezca tanto al hombre como el amor sin medida.

A mi hermana: Por demostrar siempre tu amor, con palabras y con acciones. Tu expresividad es una

cualidad de la que yo carezco, pero ha sido siempre un puente para mantener la unión en los eslabones más débiles de nuestra relación familiar.

Has estado siempre ahí para cuidarme cuando era necesario y asumir tu papel. Gracias por todo.

A mi abuela: Por ser una segunda madre para mí. Gracias por los cuidados y regaños que todavía

recibimos. Por las oraciones en mi nombre y las bendiciones diarias cada mañana y cada noche. Con el paso del tiempo he aprendido el valor de tenerla todavía conmigo, como un

tesoro de historias y experiencias y, más que nada, de amor.

Agradecimiento

A CONACYT por el apoyo económico otorgado para la realización de este proyecto.

A mi director de tesis, Dr. José Antonio Zárate Marceleño, por brindarme su ayuda y consejo en el desarrollo de esta investigación, por su profesionalismo y su calidad humana. A mi codirector, Dr. Juan Gabriel González Serna, a quien admiro por su dedicación en el trabajo.

A los revisores de esta tesis de investigación, M.C. Hugo Estrada Esquivel, M.C. Mario Guillén y M.C. Reynaldo Alanís Cantú, por su disposición, sus valiosos comentarios y observaciones.

Al Centro Nacional de Investigación y Desarrollo Tecnológico y a todo el personal que labora en esta institución. En especial al M.C. Hugo Estada Esquivel, quien confió siempre en mis capacidades y me brindó su amistad sincera. A la Dra. Azucena Montes Rendón y al Dr. Máximo López Sánchez.

A Eduardo, por tu cariño constante y sincero. Mil gracias por la oportunidad de conocer a un hombre maravilloso de quien solo puedo expresarme de la mejor manera. Gracias también por creer en mí.

Al Lic. Andrés Díaz Elizalde, por ser siempre un valioso ejemplo y haber encontrado en su amistad una guía moral que me ha ayudado a madurar en muchos aspectos de mi vida.

A mis amigos: María Magdalena, Yazmin, Adriana, Abdiel, Hugo Alberto, Christian Emmanuel y Cristian Servelio. Por acompañarme en los momentos de incertidumbre y en las alegrías de todos los días.

A mis amigos del cenidet: Jorge Alberto, por ser una persona maravillosa y amable que con algunas reservas me compartió su sentir. Edgar Omar, por los consejos a distancia y el apoyo incondicional, espero que podamos contar siempre el uno con el otro. Ismael Rafael, por tu carácter noble y tu actitud desinteresada, y en especial a Jesús Guillermo por tu compañía y contagiosa fortaleza de espíritu cuando más me hizo falta, por ser mi amigo a pesar de todo siempre tendrás un lugar especial en mi corazón.

Para mis tíos Raymundo, Gloria, Roberto y Rosalía, quienes están siempre al pendiente, a pesar de la distancia. A todos, mil gracias.

Matilde Baños Nolasco.

Resumen

Los sitios Web son un recurso para distribuir información, utilizados para distintos propósitos, como: informativos, transaccionales, de comunidad, entretenimiento, comerciales, de gobierno, de educación, personales, entre otros.

Por su naturaleza, los sitios Web, poseen estructuras difíciles de entender, debido a la multiplicidad de sus enlaces y la falta de semántica en éstos.

El uso de enlaces entre páginas sin entender el significado semántico de lo que relacionan, genera una estructura bajo el esquema de organización de “Web pura” [Powell 2002]. Este tipo de esquema resta claridad a la estructura. Diversos estudios como los realizados por el IHMC demuestran que el aprendizaje se basa en el uso de relaciones entre conceptos. Es por ello que resulta necesario agregar semántica que ayude a entender cómo están relacionados entre sí los elementos que conforman el sitio Web.

Se han realizado análisis de diferentes enfoques para la búsqueda de la definición

formal de las relaciones. Algunos de estos enfoques son: las relaciones semánticas definidas en la lingüística (en este trabajo se hizo hincapié en una de ellas, la meronimia) y propiedades de UML.

El presente trabajo describe una metodología que utiliza conceptos de diseño de

ontologías para crear estructuras. La metodología propuesta muestra que la construcción del sitio implica el uso de un conjunto de relaciones entre sus elementos (páginas, archivos multimedia, entre otros), donde las relaciones corresponden a los enlaces. Con esto se intenta proporcionar una solución a la falta de semántica de la arquitectura de los sitios Web. Para llevar a cabo esta tarea se siguió un proceso de análisis sobre un dominio específico. Posteriormente se determinaron patrones de construcción que ayudaron a obtener conceptos propios del dominio para conformar una jerarquía de clases. Se establecieron relaciones entre los conceptos, una tipificación de dichas relaciones, siendo ésta la principal aportación de este trabajo y además, se implementó un editor de sitios Web basado en los resultados del análisis anterior.

Abstract

Websites are a resource for distributing information, used for different purposes such as: informative, transactional, community, entertainment, business, government, educational, personal ones, among others. Because of its nature, Websites, have structures difficult to understand, due to the multiplicity of their links and the lack of semantics in these.

The use of links among pages without understanding the semantic meaning of what

they relate generates a structure under the "pure web" organization scheme [Powell 2002]. This type of scheme reduces clarity to the structure. Several studies, such as the ones coming from the IHMC’s, show that the learning process is based in the use of relations among concepts. Therefore, is necessary to add semantics to the Web site structure such that they help to understand how the elements forming it are interrelated among them. There have been done analyses of different approaches for the searching of formal definition of the relations. Some of these approaches are: the semantic relations, mereology characteristics and UML properties.

The present work describes a methodology that uses ontology design concepts in

order to create structures. The proposed methodology shows that the construction of the site implies the use of a set of relations among its elements (pages, multimedia files, and others), where relations fit to links. This is an attempt to provide a solution to the lack of semantics in Websites architecture.

To carry out this task an analysis process was followed over a specific domain. Afterwards construction patterns were determined that help to obtain concepts of the domain to conform a hierarchy of classes. Relations among concepts were established, a categorization of such relations, being this the principal contribution of this work, and it was also developed a Website editor based on the results of the previous analysis.

Página i

Índice de contenido CAPÍTULO 1. INTRODUCCIÓN ..................................................................................................................... 1

1.1. ANTECEDENTES .......................................................................................................................................... 2 1.2. DESCRIPCIÓN DEL PROBLEMA ........................................................................................................................ 3 1.3. OBJETIVO.................................................................................................................................................. 3 1.4. JUSTIFICACIÓN ........................................................................................................................................... 4 1.5. ALCANCES ................................................................................................................................................. 5 1.6. LIMITACIONES ............................................................................................................................................ 5 1.7. BENEFICIOS ............................................................................................................................................... 6 1.8. ORGANIZACIÓN DEL DOCUMENTO .................................................................................................................. 6

CAPÍTULO 2. MARCO TEÓRICO ................................................................................................................... 8

2.1. CONCEPTO ................................................................................................................................................ 9 2.2. SITIO WEB ................................................................................................................................................ 9 2.3. ARQUITECTURA DE SITIOS WEB ..................................................................................................................... 9 2.4. ONTOLOGÍA ............................................................................................................................................ 10 2.5. DISEÑO WEB ........................................................................................................................................... 10 2.6. USABILIDAD ............................................................................................................................................ 11 2.7. MAPA CONCEPTUAL .................................................................................................................................. 11 2.8. XML ...................................................................................................................................................... 12 2.9. OWL ..................................................................................................................................................... 12 2.10. RELACIÓN ............................................................................................................................................... 12

2.10.1. Relación de hiperonimia-hiponimia ........................................................................................... 13 2.10.2. Relación Sintagmática ................................................................................................................ 13 2.10.3. Relación de meronimia .............................................................................................................. 14

2.10.3.1. Mereología ............................................................................................................................................ 14 2.10.3.2. Meronimias centrales ........................................................................................................................... 15 2.10.3.3. Meronimias no centrales ...................................................................................................................... 15 2.10.3.4. Propiedades secundarias de las relaciones parte-todo ......................................................................... 16

2.10.4. Relación topológica .................................................................................................................... 17 2.11. UML ..................................................................................................................................................... 17

2.11.1. Propiedades de las relaciones de agregación y composición para UML................................... 17 2.12. SISTEMAS DE NAVEGACIÓN DE SITIOS WEB .................................................................................................... 18

2.12.1. Conjunto primario de navegación ........................................................................................ 18 2.12.2. Conjunto secundario de navegación .................................................................................... 18 2.12.3. Conjunto terciario de navegación .............................................................................................. 18

CAPÍTULO 3. ESTADO DEL ARTE ................................................................................................................ 20

3.1. WEBTOC ............................................................................................................................................... 21 3.2. DREAMWEAVER ...................................................................................................................................... 22

3.2.1. Visualización del mapa del sitio ...................................................................................................... 22 3.3. SGMAPPER ............................................................................................................................................. 23

3.3.1. Organización jerárquica del sitio Web ............................................................................................ 23 3.3.2. Organización de red del sitio Web .................................................................................................. 23 3.3.3. Enlaces asociativo implícito ............................................................................................................ 23 3.3.4. Formato SGF ................................................................................................................................... 24 3.3.5. Implementación .............................................................................................................................. 24

3.4. URIGRAPH .............................................................................................................................................. 25 3.4.1. Capas del modelo Urigraph ............................................................................................................ 26

Página ii

3.4.2. Gramática XML ............................................................................................................................... 28 3.5. CMAPTOOLS ........................................................................................................................................... 29 3.6. OOWS (MÉTODO DE PRODUCCIÓN DE SOLUCIONES WEB ORIENTADOS A OBJETO) .............................................. 30

3.6.1. Especificación del problema ........................................................................................................... 30 3.7. TOUCH GRAPH ......................................................................................................................................... 32

3.7.1. TouchGraph propietario ................................................................................................................. 32 3.7.2. TouchGraph de código abierto ....................................................................................................... 32

3.7.2.1. LinkBrowser ........................................................................................................................................... 33 3.7.2.2. WikiBrowser .......................................................................................................................................... 34

3.8. PERSONALBRAIN ...................................................................................................................................... 34 3.8.1. El pensamiento activo .................................................................................................................... 34 3.8.2. Relaciones de pensamientos .......................................................................................................... 35

3.9. ONTOWEBBER ......................................................................................................................................... 36

CAPÍTULO 4. ANÁLISIS Y DISEÑO DE LA SOLUCIÓN ................................................................................... 38

4.1. DESCRIPCIÓN GENERAL DE LA SOLUCIÓN PROPUESTA ....................................................................................... 39 4.2. DESARROLLO DE UNA METODOLOGÍA PARA DEFINIR ESTRUCTURAS DE SITIOS WEB BASADA EN DISEÑO DE ONTOLOGÍAS 39

4.2.1. Estudio de los dominios de trabajo ................................................................................................ 39 4.2.1.1. Análisis de sitios Web de dominio educación (edu) .............................................................................. 39 4.2.1.2. Estructura de páginas ............................................................................................................................ 41

4.2.2. Construcción de una ontología del dominio de educación ............................................................ 44 4.2.2.1. Identificación del propósito de la ontología .......................................................................................... 44 4.2.2.2. Identificación de conceptos del dominio .............................................................................................. 44 4.2.2.3. Creación de la taxonomía de clases ...................................................................................................... 45 4.2.2.4. Atributos de las clases de la ontología .................................................................................................. 47 4.2.2.5. Definición de clases de la taxonomía .................................................................................................... 47 4.2.2.6. Establecimiento de relaciones de la ontología ...................................................................................... 50

4.3. EDITOR DE ESTRUCTURAS DE SITIOS WEB ...................................................................................................... 62 4.3.1. Análisis de requerimientos del usuario .......................................................................................... 62 4.3.2. Arquitectura general de la herramienta y descripción de las funciones ........................................ 62 4.3.3. Usuarios de la herramienta ............................................................................................................ 63 4.3.4. Limitaciones de la herramienta ...................................................................................................... 64

4.4. DISEÑO .................................................................................................................................................. 64 4.4.1. Diagramas de casos de uso ............................................................................................................. 64

CAPÍTULO 5. IMPLEMENTACIÓN .............................................................................................................. 69

5.1. CREACIÓN DE LA ONTOLOGÍA CON LA HERRAMIENTA PROTÉGÉ .......................................................................... 70 5.2. DESARROLLO DE LA APLICACIÓN .................................................................................................................. 71

5.2.1. Características generales de implementación ................................................................................ 71 5.2.2. Implementación de módulos .......................................................................................................... 72

5.2.2.1. Carga de la ontología............................................................................................................................. 72 5.2.2.2. Creación de grafos con la herramienta ................................................................................................. 73 5.2.2.3. Crear archivo XML a partir de un grafo ................................................................................................. 76 5.2.2.4. Generar grafo a partir de un archivo XML ............................................................................................. 78 5.2.2.5. Generar estructura del sitio Web .......................................................................................................... 79 5.2.2.6. Generar reporte de errores ................................................................................................................... 82 5.2.2.7. Validar la estructura de sitio Web ......................................................................................................... 83

CAPÍTULO 6. PRUEBAS ............................................................................................................................. 85

6.1. INTRODUCCIÓN ........................................................................................................................................ 86 6.2. HIPÓTESIS ............................................................................................................................................... 86 6.3. PRUEBA DE USABILIDAD ............................................................................................................................. 86

6.3.1. Descripción de las pruebas ............................................................................................................. 86 6.3.2. Problemas encontrados .................................................................................................................. 87

6.4. PLAN DE PRUEBAS..................................................................................................................................... 88

Página iii

6.4.1. Características a probar .................................................................................................................. 88 6.4.1.1. Pruebas de creación y edición de grafos ............................................................................................... 88 6.4.1.2. Pruebas de creación de estructuras de sitios Web ............................................................................... 89

6.4.2. Procedimiento de las pruebas ........................................................................................................ 89 6.4.2.1. EDWEB-101 Pruebas de creación y edición de grafos ........................................................................... 89 6.4.2.2. EDWEB-102 Pruebas de creación de estructuras de sitios Web ........................................................... 92

6.4.3. Resultados de las pruebas .............................................................................................................. 92

CAPÍTULO 7. CONCLUSIONES ..................................................................................................................102

7.1. CONCLUSIONES ...................................................................................................................................... 103 7.2. APORTACIONES ...................................................................................................................................... 103 7.3. TRABAJOS FUTUROS ................................................................................................................................ 103 7.4. PUBLICACIONES ...................................................................................................................................... 104

ANEXO A: .......................................................................................................................................................105

EJEMPLOS DE ETIQUETADO ...........................................................................................................................105

ANEXO B: .......................................................................................................................................................107

IMPLEMENTACIÓN .........................................................................................................................................107

REFERENCIAS .................................................................................................................................................116

Índice de figuras FIGURA 1.1. NÚMERO TOTAL DE SITIOS WEB. OCTUBRE 1995-JULIO 2008 ............................................................................. 4 FIGURA 3.1. EJEMPLO DE APLICACIÓN DE WEBTOC ........................................................................................................... 21 FIGURA 3.2. FUNCIONAMIENTO DEL CLIENTE .................................................................................................................... 25 FIGURA 3.3. EJEMPLO DE LA CAPA TOPOLÓGICA DE ............................................................................................................ 26 FIGURA 3.4. ESTRUCTURA DE LA URL EN URIGRAPH .......................................................................................................... 28 FIGURA 3.5. GRAMÁTICA XML DE URIGRAPH ................................................................................................................... 28 FIGURA 3.6. APROXIMACIÓN A LA METODOLOGÍA OOWS .................................................................................................. 30 FIGURA 3.7. EJEMPLO DE HINT ...................................................................................................................................... 33 FIGURA 3.8. TIPOS DE PENSAMIENTO .............................................................................................................................. 35 FIGURA 4.1. PÁGINA PRINCIPAL DEL CINVESTAV ............................................................................................................. 42 FIGURA 4.2. EJEMPLO DE ESTRUCTURA JERÁRQUICA ENTRE LA PÁGINA PRINCIPAL DEL CINVESTAV Y ELEMENTOS DEL GRUPO DE

NAVEGACIÓN PRIMARIO ...................................................................................................................................... 43 FIGURA 4.3. ENLACES DEL CONJUNTO SECUNDARIO DE NAVEGACIÓN ..................................................................................... 43 FIGURA 4.4. DIAGRAMA DE CLASES DE LA ONTOLOGÍA ........................................................................................................ 45 FIGURA 4.5. CONJUNTO DE RELACIONES .......................................................................................................................... 50 FIGURA 4.6. ARQUITECTURA GENERAL DEL EDITOR EDWEB ................................................................................................ 62 FIGURA 4.7. CASOS DE USO ........................................................................................................................................... 65 FIGURA 5.1. JERARQUÍA DE CLASES ................................................................................................................................. 70 FIGURA 5.2. CONJUNTO DE PROPIEDADES ........................................................................................................................ 71 FIGURA 5.3. CLASES PARA EXPLOTACIÓN DE LA ONTOLOGÍA ................................................................................................. 73 FIGURA 5.4. DIAGRAMA DE ACTIVIDADES PARA LA CREACIÓN DE GRAFOS ............................................................................... 74 FIGURA 5.5. CLASES PARA LA CREACIÓN DE GRAFOS ........................................................................................................... 75 FIGURA 5.6. DIAGRAMA DE ACTIVIDADES PARA LA CREACIÓN DE UN ARCHIVO XML ................................................................. 76 FIGURA 5.7. DIAGRAMA DE CLASES PARA LA CREACIÓN DE UN ARCHIVO XML ......................................................................... 77 FIGURA 5.8. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE UN GRAFO ................................................................................ 78 FIGURA 5.9. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE UN GRAFO ........................................................................ 79 FIGURA 5.10. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE ESTRUCTURAS DE SITIOS WEB ............................................. 80

Página iv

FIGURA 5.11. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE ESTRUCTURAS DE SITIOS WEB ..................................................... 81 FIGURA 5.12. DIAGRAMA DE CLASES PARA LA GENERACIÓN DE REPORTE DE ERRORES ............................................................... 82 FIGURA 5.13. DIAGRAMA DE ACTIVIDADES PARA LA GENERACIÓN DE REPORTE DE ERRORES ....................................................... 83 FIGURA 5.14. DIAGRAMA DE ACTIVIDADES PARA LA VALIDACIÓN DE ESTRUCTURAS DE SITIOS WEB .............................................. 84 FIGURA 5.15. DIAGRAMA DE CLASES PARA LA VALIDACIÓN DE ESTRUCTURAS DE SITIOS WEB ...................................................... 84

Índice de tablas

TABLA 2.1. RELACIONES CENTRALES DE MERONIMIA CON FACTOR DE INTERFERENCIA "OPCIONALIDAD" ....................................... 15 TABLA 2.2. MERONIMIAS NO CENTRALES DE TIPO COLECTIVIDAD .......................................................................................... 16 TABLA 4.1. CONJUNTO DE SITIOS WEB ANALIZADOS........................................................................................................... 40 TABLA 4.2. DEFINICIÓN DE CLASES DE LA TAXONOMÍA ........................................................................................................ 46 TABLA 4.3. DEFINICIÓN DE LA CLASE DESCRIPCIÓN ABSTRACTA ............................................................................................. 47 TABLA 4.4. DEFINICIÓN DE LA CLASE DESCRIPCIÓN FÍSICA .................................................................................................... 48 TABLA 4.5. DEFINICIÓN DE LA CLASE ESTUDIANTE .............................................................................................................. 48 TABLA 4.6. DEFINICIÓN DE LA CLASE ORGANIZACIÓN FUNCIONAMIENTO ................................................................................ 48 TABLA 4.7. DEFINICIÓN DE LA CLASE PRODUCTO ............................................................................................................... 48 TABLA 4.8. DEFINICIÓN DE LA CLASE SERVICIO EXTERNO ..................................................................................................... 48 TABLA 4.9. DEFINICIÓN DE LA CLASE SERVICIO INTERNO ...................................................................................................... 49 TABLA 4.10. DEFINICIÓN DE LA CLASE SUCESO .................................................................................................................. 49 TABLA 4.11. DEFINICIÓN DE LA CLASE TRABAJADOR ........................................................................................................... 49 TABLA 4.12. DEFINICIÓN DE LA CLASE TRÁMITE ................................................................................................................ 49 TABLA 4.13. DEFINICIÓN DE LA CLASE UNIDAD ORGANIZACIONAL ......................................................................................... 50 TABLA 4.14. DOMINIO Y RANGO PARA LA RELACIÓN (A) MERONIMIA FACULTATIVA-FACULTATIVA ............................................. 51 TABLA 4.15. DOMINIO Y RANGO PARA LA RELACIÓN (B) MERONIMIA FACULTATIVA-FACULTATIVA ............................................. 52 TABLA 4.16. DOMINIO Y RANGO PARA LA RELACIÓN (C) MERONIMIA GRUPO-MIEMBRO: ........................................................ 52 TABLA 4.17. DOMINIO Y RANGO PARA LA RELACIÓN (D) MERONIMIA COLECCIÓN-MIEMBRO .................................................... 53 TABLA 4.18. DOMINIO Y RANGO PARA LA RELACIÓN (E) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 53 TABLA 4.19. DOMINIO Y RANGO PARA LA RELACIÓN (F) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 54 TABLA 4.20. DOMINIO Y RANGO PARA LA RELACIÓN (G) MERONIMIA CANÓNICA-CANÓNICA .................................................... 54 TABLA 4.21. DOMINIO Y RANGO PARA LA RELACIÓN (H) MERONIMIA CANÓNICA-CANÓNICA .................................................... 55 TABLA 4.22. DOMINIO Y RANGO DE LA RELACIÓN (I) MERONIMIA CANÓNICA-CANÓNICA ......................................................... 55 TABLA 4.23. DOMINIO Y RANGO PARA LA RELACIÓN (J) MERONIMIA CANÓNICA-CANÓNICA ..................................................... 56 TABLA 4.24. DOMINIO Y RANGO PARA LA RELACIÓN (K) MERONIMIA CANÓNICA-FACULTATIVA ................................................. 56 TABLA 4.25. DOMINIO Y RANGO PARA LA RELACIÓN (L) MERONIMIA CANÓNICA-FACULTATIVA ................................................. 57 TABLA 4.26. DOMINIO Y RANGO PARA LA RELACIÓN (M) MERONIMIA CANÓNICA-FACULTATIVA ................................................ 57 TABLA 4.27. DOMINIO Y RANGO PARA LA RELACIÓN (N) MERONIMIA FACULTATIVA -CANÓNICA ................................................ 58 TABLA 4.28. DOMINIO Y RANGO PARA LA RELACIÓN TOPOLÓGICA ....................................................................................... 58 TABLA 4.29. DOMINIO Y RANGO PARA LA RELACIÓN PRODUCE ............................................................................................. 58 TABLA 4.30. DOMINIO Y RANGO PARA LA RELACIÓN REGISTRA ............................................................................................. 59 TABLA 4.31. CONJUNTO DE PROPIEDADES PARA RELACIONES MERONÍMICAS ........................................................................... 60 TABLA 4.32. PROPIEDADES DE CU-1 CREAR GRAFO DEL SITIO WEB ...................................................................................... 65 TABLA 4.33. PROPIEDADES DE CU-2 CREAR ARCHIVO XML A PARTIR DE UN GRAFO ................................................................. 66 TABLA 4.34. PROPIEDADES DE CU-3 GENERAR GRAFO A PARTIR DE UN ARCHIVO XML ............................................................. 66 TABLA 4.35. PROPIEDADES DE CU-4 GENERAR ESTRUCTURA DEL SITIO WEB .......................................................................... 66 TABLA 4.36. PROPIEDADES DE CU-5 CREAR REPORTE DE ERRORES ....................................................................................... 67 TABLA 4.37. PROPIEDADES DE CU-6 VALIDAR ESTRUCTURA DEL SITIO WEB ........................................................................... 67 TABLA 6.1. CASO DE PRUEBA EDWEB-101-001 CARGA DE LA ONTOLOGÍA .......................................................................... 93 TABLA 6.2. CASO DE PRUEBA EDWEB-101-002 CREAR UN GRAFO MANUAL ......................................................................... 94 TABLA 6.3. CASO DE PRUEBA EDWEB-101-003 GENERAR UN ARCHIVO XML ...................................................................... 94

Página v

TABLA 6.4. CASO DE PRUEBA EDWEB-101-004 GENERAR UN GRAFO AUTOMÁTICAMENTE ..................................................... 96 TABLA 6.5. CASO DE PRUEBA EDWEB-101-005 REPORTAR ENLACES INDEFINIDOS ................................................................. 97 TABLA 6.6. CASO DE PRUEBA EDWEB-101-006 VALIDAR EL GRAFO .................................................................................... 98 TABLA 6.7. CASO DE PRUEBA EDWEB-102-001 GENERAR ESTRUCTURA DEL SITIO WEB ......................................................... 99 TABLA 6.8. DESCRIPCIÓN DE GRAFOS DE LOS CASOS DE PRUEBA DE LA HERRAMIENTA EDWEB ................................................. 101

Capítulo 1. Introducción En el presente capítulo se exponen los antecedentes que dieron origen a la tesis; se describe el problema al cual se dio solución; se definen los objetivos de la presente investigación; sus alcances y limitaciones; y los beneficios que aporta. Finalmente, en el último apartado, se describe la organización del documento.

Capítulo 1. Introducción

Página 2

1.1. Antecedentes

La World Wide Web (WWW, Red Global Mundial) fue creada entre 1989 y 1990 por Tim Berners-Lee como la culminación del hipertexto, iniciando así una nueva era de difusión masiva de la información. A medida que la Web evolucionó se incrementaron sus funciones, apareciendo posteriormente los actuales navegadores y las interfaces gráficas así como diversos servicios en función de las necesidades del usuario. Éstas pueden ser de tipo informativo, transaccionales, de comunidad, entretenimiento, comerciales, de gobierno, de educación, personales, entre otras.

Con la evolución de internet surgió la necesidad de organizar la información y mejorar su explotación. Así nacieron conceptos tales como la Web semántica [W3C 2008] y se hizo popular el uso de ontologías, utilizadas desde hace varios años en diversas áreas de conocimiento, que permitieron comprender la información distribuida en la WWW

Las ontologías se fundamentan en la representación de la realidad por medio de conceptos, es decir, la abstracción de ciertos aspectos de entidades que existen en un dominio específico. Asimismo definen el modo en que dichas entidades se relacionan entre ellas. Tienen una posición central en la visión de la Web semántica, que se refiere a la integración y representación de datos, así como la manera en que se relacionan con los objetos de la vida real.

El término semántico fue introducido por el propio Berners-Lee, quien desde el inicio

de la WWW consideró la inclusión de información en las páginas de los sitios Web. Actualmente existen lenguajes y estándares para la representación de datos y la formalización de ontologías como: XML, RDF, RDF Schema y OWL, descritos en [OWL 2008]

La Web semántica brinda una mejora a internet porque proporciona información adicional que aporta significado y relaciones entre datos. Sin embargo, su propósito es facilitar la interoperabilidad entre los sistemas de información para reducir la intervención humana, es decir, que sea transparente para un usuario del sistema.

Esta tesis proporciona un enfoque dirigido al arquitecto de sitios Web, sin ignorar el impacto que tendrá en los usuarios finales del sitio. Su principal contribución consiste en una metodología basada en los conceptos de diseño de ontologías para agregar significado a las estructuras de sitios Web de un dominio específico dejando a un lado el contenido de las páginas.

La investigación realizada defiende la idea de que no sólo el contenido presenta

elementos que son utilizados para una mejor descripción del sitio Web. Sostiene además que la arquitectura posee conceptos que guardan ciertas relaciones entre ellos, en forma tal que ayudan a conceptualizar y definir un sitio Web para que su generación y mantenimiento sean más sencillos para el responsable del mismo.


Página 3

1.2. Descripción del problema

En la actualidad existen millones de sitios de diferentes ámbitos, cada uno creado de acuerdo a patrones de diseño que consideran aspectos estéticos más que de organización del sitio. Desde el comienzo de la WWW, Berners-Lee intentó integrar aspectos semánticos en los sitios Web, sin conseguirlo. En consecuencia se desencadenó un problema relacionado con la creación de los mismos. Actualmente muchas páginas no poseen metadatos que describan la información contenida en los sitios, ni datos sobre su estructura. A raíz de la creación de la Web semántica se integró la parte semántica al contenido de las páginas. Sin embargo se ha dejado a un lado la arquitectura de los sitios Web.

Actualmente existen diferentes maneras de crear un sitio Web, utilizando plantillas

Cascading Style Sheets (CSS, Hoja de Estilo en Cascada) [W3C 2008c], mapas de sitios [DICIF 2008], mapas conceptuales [Novak 84], entre otras. Hay además herramientas que permiten la implementación de estas técnicas para la elaboración de sitios Web.

El uso de plantillas CSS se aplica al diseño Web, siendo de carácter estético y no de

composición. Los mapas de los sitios se elaboran siguiendo un patrón de grafo dirigido, en el que se establece la navegación del usuario entre páginas. Pero este grafo no incluye un etiquetado que establezca la relación directa entre los elementos que componen la estructura.

En el caso de los mapas conceptuales, el usuario establece manualmente las relaciones

entre los conceptos. Sin embargo, estas relaciones no presentan algún tipo de validación y mucho menos ayudan a definir su semántica.

Los métodos anteriores muestran la estructura de un sitio, proporcionan vistas del

acomodo de los elementos de las páginas y sugieren un modo de diseñar el sitio Web, pero no definen el significado de su estructura o, si lo hacen, no permiten su posterior utilización, a diferencia del enfoque presentado en este trabajo.

La importancia del problema señalado radica en la relevancia que adquiere la

estructura en el proceso de elaboración del sitio Web debido a que es la base que soporta la organización lógica de su información y su posterior mantenimiento. Una buena arquitectura del sitio Web asegura que el proceso de diseño sea más eficiente, lo cual no se logra si el diseñador no es capaz de expresar de manera clara cómo está conformada la estructura.

1.3. Objetivo

El objetivo de este trabajo de investigación es proporcionar elementos que permitan al arquitecto de sitios Web construir estructuras dotadas de significado que proporcionen mayor grado de comprensión y ayuden en la creación y mantenimiento del sitio. Para cumplir con este objetivo, se distinguen las siguientes actividades:


Página 4

Estudiar los conceptos referentes al diseño de ontologías y la manera en que se aplican a la arquitectura de sitios Web.

Desarrollar una metodología para construir sitios Web basada en diseño de ontologías.

Elaborar un editor de sitios Web para validar la metodología de construcción de sitios Web.

1.4. Justificación

En el presente apartado se indican los puntos que justifican el trabajo de investigación realizado.

En base a una larga búsqueda no se encontraron trabajos que definan un modo de estructurar los sitios Web o que involucren una lógica de construcción al momento de realizar el modelado. La propuesta más cercana a este trabajo se refiere al uso de mapas conceptuales, en los que las relaciones y los conceptos sólo tienen significado para el arquitecto del sitio Web y no un significado preestablecido. Otros trabajos como [Adobe 2007], [Liechti 1998], [IHCM 2007], [TouchGraph 2007a], [Brain 2007] y [Jin 2001] sólo han desarrollado herramientas que visualizan el grafo del sitio Web.

El uso de sitios Web se ha diversificado y extendido con rapidez. De acuerdo a las estadísticas proporcionadas por el sitio [Netcraft 2008], en marzo del 2008 existían 162,662,052 sitios Web y para julio del 2008 la cantidad aumentó a 175,480,931 . Las cifras anteriores confirman la necesidad de incorporar semántica a la organización de los sitios Web.

Figura 1.1. Número total de sitios Web. Octubre 1995-Julio 2008

Fuente: http://news.netcraft.com/archives/2008/07/index.html


Página 5

Estudios realizados por el Instituto para el Conocimiento Humano y Máquina (Institute for Human and Machine Cognition), revelan que el ser humano aprende y recuerda el conocimiento significativo a través de un conjunto de relaciones entre conceptos. Los mapas conceptuales aplican esta idea y ayudan a las personas a examinar diversos campos de conocimiento [Cañas 2001]. Utilizar elementos como mapas de conceptos en las estructuras de sitios Web implica que será más fácil para los diseñadores y usuarios utilizar estos sitios. Sin embargo, sería de mayor utilidad formalizar dichas relaciones y conceptos, tal como se establece en este trabajo.

El modelo relacional evolucionó hasta convertirse en el modelo entidad-relación que proporcionó semántica a su predecesor, pues el modelo relacional carecía de poder expresivo. Dicha evolución coloca al modelo relacional en un nivel inferior comparado con el modelo entidad-relación [Silberschartz 2006]. Integrar un componente semántico a la arquitectura de sitios Web, de la misma forma que el modelo entidad-relación añadió semántica al modelo relacional, conducirá a mejoras en la construcción en su estructura. De la misma manera, significaría una evolución con respecto a las herramientas utilizadas en la actualidad para producir grafos de sitios Web, debido a que estas herramientas trabajan de un modo similar al modelo relacional.

1.5. Alcances

A continuación se listan los puntos cubiertos en la tesis:

Estudiar las metodologías para diseño de ontologías. Analizar una muestra del dominio de sitios Web de educación, como caso de estudio. Estudiar las relaciones aplicables en la construcción de sitios Web, partiendo del

análisis de relaciones definidas en la lingüística y en UML. Definir formalmente las relaciones encontradas en el caso de estudio. Definir formalmente las clases de conceptos encontradas en el caso de estudio. Crear una herramienta para la edición de sitios Web con fines de prueba de la

metodología propuesta. El editor creado permite al usuario crear sitios Web y almacenar archivos descriptivos

de sus estructuras, así como generar páginas en blanco de dicha estructura.

1.6. Limitaciones

Se listan los puntos no cubiertos que delimitan el alcance de este trabajo.

La herramienta propuesta no ofrece la funcionalidad de crear un sitio Web de manera

automática, sino únicamente una estructura relacionada del sitio conformada de páginas en blanco que pueden ser editadas posteriormente por medio de herramientas de diseño.

Las relaciones definidas no contemplan elementos dinámicos ni de contenido del sitio Web (imagen, texto, etc.).


Página 6

Se contemplan en los casos de uso la creación de un sitio Web nuevo, visualización de grafos creados a partir de archivos XML existentes y evaluación de un sitio Web editado con la herramienta.

En el caso de la creación de un sitio Web, no se etiqueta automáticamente el grafo, sino que el diseñador se encarga de tomar las relaciones convenientes para utilizarlas según se da el caso.

Las pruebas de usabilidad realizadas validan la hipótesis de las mejoras con respecto a la construcción y mantenimiento del sitio, no las posibles mejoras que encuentra un usuario al navegar por el sitio, es decir, estas pruebas se dirigen a quien crea el sitio y no a los usuarios finales del mismo.

No se contemplan elementos de diseño gráfico de la interfaz de usuario.

1.7. Beneficios

Los beneficios que derivados de esta tesis de investigación se listan a continuación:

La metodología establece conceptos y relaciones predefinidas como soporte en la

creación de sitios Web, elementos que hasta el momento no son ofrecidos por otras metodologías de construcción de sitios Web.

La metodología propuesta incluye la creación que una ontología que puede compartirse y extenderse, por lo que puede aplicarse a otros dominios de sitios Web.

Se valida la semántica de las relaciones predefinidas y su equivalente en una implementación.

El editor permite agregar una estructura lógica del sitio Web, partiendo de la metodología propuesta.

El diseñador del sitio se beneficia al poseer una herramienta que, al etiquetar el sitio, le permite más adelante, en caso de ser necesario, realizar cambios a la estructura de un modo más fácil.

Los sitios Web estructurados a partir de su semántica pueden brindar un mayor grado de comprensión para el diseñador del sitio.

1.8. Organización del documento

El documento de tesis se organiza en las secciones que se listan a continuación:

Capítulo 1: Introducción. Ubica al lector en el contexto del trabajo de investigación.

Hace referencia al panorama general del tema desarrollado.

Capítulo 2: Marco teórico. Contiene el conjunto central de conceptos que ayudan a la

comprensión de la investigación.

Capítulo 3: Estado del arte. Resume los trabajos relacionados, encontrados en la

literatura y que sirven como punto de referencia y comparación con el trabajo

propuesto.

Capítulo 4: Análisis y diseño de la solución.

Capítulo 5: Desarrollo de la investigación.


Página 7

Capítulo 6: Implementación. Incluye elementos de codificación y las clases utilizadas

en cada caso de uso propuesto en el análisis.

Capítulo 7: Pruebas. Se desarrollan los casos de prueba previstos en el plan de

pruebas para el editor creado.

Capítulo 8: Conclusiones. Proporciona los resultados y observaciones finales de este

trabajo de investigación.

Capítulo 2. Marco teórico

Se expone a continuación, el conjunto de conceptos que sirven de guía al lector para tener una mejor comprensión del trabajo desarrollado.


Página 9

2.1. Concepto

Un concepto, de acuerdo a la recopilación de Sager en diversas instituciones

estandarizadas [Sager 1990], puede definirse de acuerdo a las siguientes acepciones:

Los conceptos son constructos mentales, abstracciones que se pueden emplear para clasificar los distintos objetos del mundo exterior e interior (Recomendación Estándar Británica para la selección, formación y definición de términos técnicos).

Los objetos de todos los campos de conocimiento y actividades humanas, las cosas, sus propiedades, cualidades, fenómenos, etc., se representan mediante conceptos (Propuesta de revisión del Reino Unido para el documento de la ISO R/704).

Un concepto es un constructo mental para la clasificación de objetos individuales del mundo exterior e interior por medio de una abstracción más o menos arbitraria (Borrador de 1968 del estándar ISO 704).

Un concepto es una unidad de pensamiento, generada mediante la agrupación de objetos individuales relacionados entre sí por características comunes (Borrador de documento DIN, alemán).

Un concepto es un grupo coherente de juicios sobre un objeto cuyo núcleo se compone de aquellos juicios que reflejan las características inherentes del objeto (Propuesta de la Unión Soviética para la revisión del documento ISO 704).

Un concepto es una unidad de pensamiento.

2.2. Sitio Web

Un sitio Web es una serie o colección de páginas que definen la estructura del mismo y se identifican por una única dirección, Localizador Uniforme de Recurso (URL) [Cooley 2000]. Un sitio Web puede ser modelado como un grafo dirigido con nodos Web y arcos Web, donde los nodos corresponden a tipos de páginas (tales como HTML, PHP, ASP, CGI, JSP, etcétera.), y los arcos corresponden a los hipervínculos interconectando a las páginas Web [Lee 2006].

2.3. Arquitectura de sitios Web

De acuerdo con [Greenwich 2007], se define arquitectura de sitios Web como el arte y ciencia de crear buenos sitios Web, en donde se proporciona una amplia aproximación a la planeación y diseño de sitios Web. Se le llama arquitectura, porque, tal como lo hace arquitectura tradicional, implica aspectos de ingeniería, estéticos y funcionales, siendo algunos de sus requerimientos:

Contenido útil y bien organizado [Utilidad y comodidad]. Buenas técnicas de diseño [Eficiencia y firmeza]. Buen diseño visual [Belleza].


Página 10

La arquitectura de sitios Web requiere especial atención al contenido Web, el plan de negocio de la empresa, la usabilidad, el diseño de interacción, la arquitectura de la información y el diseño Web.

Los puntos tradicionales de comodidad, firmeza y satisfacción que pueden guiar la

arquitectura de sitios Web se encuentran dentro de las etapas que inician con la planeación del contenido Web hasta el manejo del mismo, de la manera en que se encuentran en la arquitectura física y otras disciplinas de diseño.

2.4. Ontología

Especificación explícita y formal de una conceptualización compartida [Gruber 1993]. En esta definición, convertida ya en estándar, conceptualización se refiere a un modelo abstracto de algún fenómeno del mundo del que se identifican los conceptos que son relevantes; explícito hace referencia a la necesidad de especificar de forma consciente los distintos conceptos que conforman una ontología; formal indica que la especificación debe representarse por medio de un lenguaje de representación formalizado y compartida refleja que una ontología debe, en el mejor de los casos, dar cuenta de conocimiento aceptado (como mínimo, por el grupo de personas que deben usarla).

La ontología es una descripción de conceptos pertenecientes a un dominio, así como las relaciones existentes entre ellos. El estudio de las ontologías nace de la filosofía y proviene de las etimologías griegas “ontos” (el ser) y “logos” (estudio), que significaría el estudio del ser.

El término ontología en informática hace referencia al intento de formular un exhaustivo y riguroso esquema conceptual dentro de un dominio dado, con la finalidad de facilitar la comunicación y la compartición de la información entre diferentes sistemas.

2.5. Diseño Web

Búsqueda multidisciplinaria perteneciente al planeamiento y producción de sitios Web, incluyendo, pero no limitada a: desarrollo técnico, estructura de la información, diseño visual y entrega a través de la red [Powell 2002]. Hay cinco áreas que cubren la mayoría de las facetas del diseño Web:

Contenido: incluye la forma y organización del contenido del sitio. Puede tener un rango que va desde cómo el texto es escrito hasta cómo es organizado, presentado y estructurado, usando tecnologías tales como HTML.

Visual: se refiere a la disposición de la pantalla usada en un sitio. La disposición es creada usualmente con HTML, CSS o incluso Flash y puede incluir elementos gráficos de tipo decorativo o para navegación. El aspecto visual del sitio es el más obvio del diseño Web, pero no el único o el más importante.

Tecnológico: mientras el uso de varias tecnologías Web de capa, como HTML o CSS, caen dentro de esta categoría, tecnología en este contexto se refiere comúnmente a los


Página 11

diversos elementos interactivos del sitio, particularmente aquellos construidos usando técnicas de programación. Tales elementos comprenden los lenguajes de guión del lado cliente, como JavaScript, y las aplicaciones del lado servidor, como los Java Servlets.

Envío: la velocidad y confiabilidad del envío de un sitio sobre internet o una red interna de una corporación está relacionada con el software y hardware del servidor usado y la arquitectura de red empleada.

Propósito: la razón de que el sitio exista, regularmente relacionado a aspectos económicos, es la parte más importante del diseño Web. Este elemento debe ser considerado en todas las decisiones que envuelvan a las otras áreas.

2.6. Usabilidad

La usabilidad, de acuerdo a [Nielsen 2003], es un atributo de calidad que mide lo fáciles de usar que son las interfaces de usuario. La palabra usabilidad se refiere además a los métodos para proveer facilidad de uso durante el proceso de diseño. La usabilidad se define por cinco componentes de calidad:

Aprendizaje: qué tan fácil es para los usuarios lograr las tareas básicas la primera vez que se enfrentan al diseño.

Eficiencia: una vez que los usuarios han aprendido el diseño, qué tan rápido desempeñan las tareas.

Recordable: cuando los usuarios usan el diseño después de un periodo de no usarlo, qué tan fácil se restablece su habilidad.

Errores: cuántos errores comete el usuario y qué tan fácil se recupera de ellos. Satisfacción: qué tan placentero resulta el diseño para el usuario.

2.7. Mapa conceptual

Los mapas conceptuales, desarrollados por Novak [Novak 1984] son usados para representar gráficamente conocimiento en todos los dominios, bajo la idea de que, en esta forma, el conocimiento puede ser fácilmente entendido por otros.

De acuerdo a los trabajos de investigación de Cañas [Cañas 2003], los mapas conceptuales están conformados de conceptos y relaciones entre ellos. Se define concepto como una regularidad percibida en un evento u objeto, o una serie de eventos u objetos, designado por una etiqueta. Los conceptos se encierran usualmente en círculos o cajas y las relaciones entre conceptos son indicadas por líneas de conexión que los enlazan. Las palabras en los enlaces especifican las relaciones entre los conceptos. La etiqueta para la mayoría de los conceptos es una sola palabra, aunque algunas veces se utilizan símbolos como + o %. La tripleta concepto-enlace-concepto conforma una proposición, es decir, una sentencia significativa sobre algún objeto o evento.


Página 12

Otra característica de los mapas conceptuales es que los conceptos son representados en forma jerárquica con los conceptos más inclusivos en la parte superior del mapa y los conceptos más específicos debajo del mapa.

Además, algo importante y característico de los mapas conceptuales es la inclusión de enlaces cruzados. Esto crea una relación explícita entre conceptos en diferentes regiones o dominios dentro del mapa conceptual. Los enlaces cruzados muestran cómo un concepto, dentro de un dominio de conocimiento representado en el mapa, está relacionado con otro concepto en otro dominio mostrado en el mapa.

Los mapas conceptuales se aplican en diferentes áreas, una de ellas es la navegación

en internet.

2.8. XML

El metalenguaje Extensible Markup Language (XML, Lenguaje de Marcas Extensible) [W3C 2008b] es una simplificación y adaptación del Standard Generalized Markup Language (SGML, Lenguaje de Marcación Estandarizado) y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML) en un formato de texto simple y flexible. Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de los lenguajes que usan XML para su definición son: eXtensible Hypertext Markup Language (XHTML, Lenguaje Extensible de Marcado de Hipertexto), Scalable Vector Graphics (SVG, Gráfico Vectorial Escalable), Mathematical Markup Language (MathML, Lenguaje de Marcado Matemático).

XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.

2.9. OWL

Web Ontology Language (OWL) está diseñado para ser usado por aplicaciones que necesitan procesar el contenido de la información en lugar de solo presentar información al ser humano. OWL proporciona una mayor interpretabilidad del contenido Web que el soportado por XML, RDF y RDF Schema (RDF-S), proveyendo vocabulario adicional junto con semánticas formales. OWL tiene tres sublenguajes incrementalmente expresivos: OWL Lite, OWL DL y OWL Full [Mc GUINESS 2004].

2.10. Relación

Las relaciones en las ontologías se representan a través de tripletas, donde los elementos se toman de dos conjuntos C y R, cuyos elementos son llamados conceptos y relaciones.


Página 13

De este modo existe una función de relación entre dos conceptos del conjunto C,

donde uno es el dominio y otro el rango, enlazados por medio de un elemento del conjunto R de relaciones.

2.10.1. Relación de hiperonimia-hiponimia

Una relación léxica de tipo genérico-específico [SIL 2008] es una asociación jerárquica entre unidades léxicas con un significado más amplio y general y otra unidad léxica con un significado más reducido y específico.

Dentro de esta relación, se envuelve la asociación entre:

Hipónimo: una unidad léxica (X) específica, con mayor complejidad semántica.

Hiperónimo: una unidad léxica (Y) general, con menor complejidad semántica.

X es un hipónimo de Y si:

La sentencia “X es necesariamente Y” es normal.

La sentencia “Y es necesariamente X” no es normal.

2.10.2. Relación Sintagmática

El sintagma es un término acuñado por [Saussure 1983], quien lo define así:

«Las palabras contraen entre sí, en virtud de su encadenamiento, relaciones fundadas en el carácter lineal de la lengua, que excluye la posibilidad de enunciar dos elementos a la vez. Los elementos se alinean uno tras otros en la cadena del habla. Estas combinaciones que se apoyan en extensión se pueden llamar sintagmas.

El sintagma se compone de dos o más unidades consecutivas (p. ej. re-leer; contra todos; la vida humana; Dios es bueno; si hace buen tiempo, saldremos; etc.) y colocado en un sintagma un término sólo tiene valor porque se opone al que le precede o al que le sigue o a ambos...La noción sintagma no sólo se aplica a las palabras, sino también a los grupos de palabras, a las unidades complejas de toda dimensión y de toda especie (palabras compuestas, derivadas, miembros de oración, oraciones enteras)...La oración es el tipo por excelencia de sintagma». Para los fines propuestos se utilizan los sintagmas predicativos, definidos por [Trubetzkoy 1939], que se encuentran compuestos por un sujeto y un predicado.


Página 14

2.10.3. Relación de meronimia

La meronimia es una relación semántica no-simétrica entre los significados de dos palabras dentro del mismo campo semántico1. Se denomina merónimo a la palabra cuyo significado constituye una parte del significado total de otra palabra, denominada ésta holónimo. Por ejemplo, dedo es merónimo de mano y mano es merónimo de brazo; a su vez, brazo es holónimo de mano y mano es holónimo de dedo.

La relación de meronimia se define de la siguiente manera [DÍEZ 1999]:

Es la relación que existe entre partes y todo.

Es diferente de la hiponimia: un brazo no es un tipo de cuerpo, sino parte del

cuerpo.

Están sujetas a construcciones posesivas inalienables (frente a las alienables como

Juan tiene un libro o El libro de Juan). Esto quiere decir que las construcciones

posesivas no pueden transmitirse ni cederse.

2.10.3.1. Mereología

Mereología es la teoría de las relaciones de parte y todo y las relaciones de partes en un todo. Sus raíces comienzan en la filosofía, con el atomismo Presocrático y los escritos de Platón y Aristóteles.

En todas las teorías filosóficas de partes, la relación meronimia significa un orden parcial; es decir, una relación reflexiva, antisimétrica y transitiva, representada por los siguientes axiomas conocidos como Ground Mereology, pertenecientes a la Mereología Minimal:

x es parte de sí mismo

Si x es parte de y y y es parte de x, entonces x y y son iguales

Si x es parte de y y y es parte de z, entonces x es parte de z

Se define también dentro de esta teoría la parte propia con sus correspondientes axiomas:

x no es parte propia de sí mismo

1 Campo semántico: conjunto de palabras o elementos significantes con significados relacionados.


Página 15

Si x es parte propia de y, entonces y no es parte propia de x

Si x es parte propia de y y y es parte propia de z, entonces x es parte propia de z

Las relaciones anteriores pueden denominarse “primitivas”, por lo que la Mereología Minimal evolucionó a lo que se conoce como Mereología Extensional y ésta, a su vez, a la Mereología Clásica, que incluye las operaciones de suma, producto, diferencia y complemento. 2.10.3.2. Meronimias centrales

Las meronimias centrales son un conjunto de relaciones encontradas en el trabajo de [Cruse 1986] que tienen su fundamento en relaciones de tipo léxico paradigmático y se aplican entre partes y todos de entidades físicas cohesionadas y tangibles, tomando en cuenta un factor de interferencia llamado “Opcionalidad” (Tabla 2.1).

Tabla 2.1. Relaciones centrales de meronimia con factor de interferencia "Opcionalidad"

Relación Descripción

Meronimia Canónica-Canónica2 Todo con parte obligatoria, parte obligatoria de un todo.

Meronimia Facultativa-Facultativa3 Todo con parte opcional, parte opcional de un todo.

Meronimia Facultativa-Canónica4 Todo con parte opcional, parte obligatoria de un todo.

Meronimia Canónica-Facultativa5 Todo con parte obligatoria, parte opcional de un todo.

Existen otras meronimias centrales con factores de interferencia tales como: congruencia,

espectro de sentidos y la holo-meronimia. 2.10.3.3. Meronimias no centrales

Las meronimias no centrales se encuentran, al igual que las centrales, en los trabajos de [Cruse 1986]. Las meronimias tomadas en cuenta en lo consecutivo son las colectividades, que se refieren a un tipo de entidades menos integrado estructuralmente que los objetos y sus partes son todas independientes –y a menudo diferenciadas- de un tipo más básico.

2 Meronimia C-C (en este documento)

3 Meronimia F-F (en este documento)

4 Meronimia F-C (en este documento)

5 Meronimia C-F (en este documento)


Página 16

Tabla 2.2. Meronimias no centrales de tipo colectividad

Relación Descripción

Grupo-Miembro Asociaciones de humanos con un propósito o función común.

Clase-Miembro Agrupación con atributos comunes. Colección-Miembro Agrupación de objetos inanimados.

Otros tipos de meronimias no centrales son: lugares, ingredientes, partículas y

medidas.

2.10.3.4. Propiedades secundarias de las relaciones parte-todo A continuación se describen brevemente las propiedades de las meronimias contempladas en la Mereología Minimal, descritas en [Guizzardi 2005]. Estas propiedades son llamadas características secundarias y no están contempladas en las teorías de mereología clásica.

Parte exclusiva: x de tipo A es una parte (propia) exclusiva de otro individuo y de tipo

B si y sólo si y es el único B que tiene a x como parte.

Relación parte-todo exclusiva general (Gx): un universal A se relaciona con un B

universal por una relación de éste tipo, si cada instancia x de A tiene una parte

exclusiva de tipo B. Para toda x que pertenece a A existe una y que pertenece a B, tal

que x es parte de y.

Parte compartida: una parte compartida representa que las instancias de una clase no

pueden ser compartidas, pero el concepto representado por esa clase sí. Las partes

compartidas se consideran como roles explícitos. La etiqueta {conceptual} es

propuesta por [Saksena 1998], para representar el concepto compartido.

Dependencia existencial: denota existencia. Un individuo x es existencialmente

dependiente sobre otro individuo y, simbolizado como si y sólo si y debe

existir cuando x existe o formalmente:

Parte esencial: un individuo x es una parte esencial de y si y sólo si y es

existencialmente dependiente de x y x es necesariamente una parte de y. Se distingue

a la parte esencial con la etiqueta {essential=true}.

Parte obligatoria: un individuo x es una parte obligatoria de otro individuo y si y sólo

si y es genéricamente dependiente de un universo U que x instancia y y tiene

necesariamente como parte una instancia de U.

Individual extensional: un individuo y es llamado un individual extensional si y sólo

si para cada x tal que x es parte de y, x es una parte esencial de y.


Página 17

Parte inseparable: un individuo x es una parte inseparable de otro individuo y si y

sólo si x es existencialmente dependiente sobre y y si x es necesariamente una parte de

y. Se distingue la parte inseparable con la etiqueta {inseparable=true}.

Todo obligatorio: un individuo y es un todo obligatorio para un individuo x si y sólo

si x es necesariamente parte de una instancia individual de U.

2.10.4. Relación topológica

La relación topológica [Díez 1999] es una relación léxica paradigmática que ocurre entre una unidad léxica que denota un contenedor, área o duración temporal y una unidad léxica que denota lo que está contenido en ellos o en un lugar alrededor. Es una relación que puede ser confundida con una meronimia. El dominio de la relación es un sustantivo (objeto de referencia) y el rango de la misma es otro sustantivo (objeto contenido o colocado en un lugar alrededor del objeto de referencia).

2.11. UML

Unified Modeling Language (UML, Lenguaje de Modelado Unificado) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas de software, así como para modelar negocios y otros sistemas que no son de software [UML 2005].

2.11.1. Propiedades de las relaciones de agregación y composición para UML

En [Manoli 2004] se plantea una diferenciación de las relaciones de agregación, composición y asociación a partir de ciertas características de UML, sin embargo, no es posible aplicarlas de manera directa como relaciones entre entidades de un sitio Web, debido a la naturaleza de las mismas. Es por ello que, a partir de la teoría sobre relaciones de este tipo se ha hecho una adaptación de las mismas.

Multiplicidad: la multiplicidad determina cuántos objetos participan en la relación, si una multiplicidad mínima es 0, indica que la relación es opcional, mientras que una multiplicidad mínima mayor o igual a 1 indica una relación obligatoria.

Propagación de borrado: indica qué acción debe ser ejecutada cuando un objeto es borrado (sobre sus enlaces o sus objetos asociados).

o {Restringida}: si el objeto tiene enlaces, no debe ser borrado. o {Cascada}: si el objeto tiene enlaces, los enlaces y los objetos asociados deben

ser borrados. o {Enlace}: si el objeto tiene enlaces, los enlaces deben ser borrados, no los

objetos asociados. Comportamiento temporal: especifica que una instancia puede ser conectada o

desconectada dinámicamente (creando o destruyendo un enlace) con una o más


Página 18

instancias de una clase relacionada (por medio de relaciones de asociación/agregación) durante su existencia.

o Dinámico: indica que es posible crear o destruir un enlace durante el tiempo de vida completo del objeto.

o Estático: indica que el comportamiento anteriormente descrito solo es posible durante el proceso de creación.

2.12. Sistemas de navegación de sitios Web

Los sistemas de navegación son una pieza importante en la experiencia del usuario del sitio Web. De acuerdo a Rosenfeld [Rosenfeld 2006] existen tres conjuntos de navegación que se describen a continuación.

2.12.1. Conjunto primario de navegación

Este conjunto indica los accesos invariables del sitio, como una estructura de árbol, donde la página principal es el nodo raíz del que se desprenden los hijos, conformando un sistema de navegación jerárquico. Los enlaces de este tipo son estructurales, pues se encuentran definidos de manera fija en estructuras de acceso como menús y no embebidos en la información de las páginas, como se presenta en los sistemas de hipertexto6.

2.12.2. Conjunto secundario de navegación

Posee enlaces que normalmente son temporales, pues representan información relevante dentro del sitio en un momento específico, por lo que pueden desaparecer en cuanto pierden su carácter de importancia. Esta información proviene también de secciones internas del sitio, creando enlaces que rompen con el esquema de jerarquía orientándose a un estilo de Web pura.

Estos enlaces de tipo hipertextual se forman entre los elementos del árbol

proporcionando mayor flexibilidad a la navegación y añadiendo o retirando componentes.

2.12.3. Conjunto terciario de navegación

Contiene enlaces que aparecen en todo el sitio, por ejemplo, la función de búsqueda. A este esquema se le conoce también como sistema de navegación global.

6 Los sistemas de hipertexto se enfocan al contenido y sus relaciones.


Página 19

La identificación de los esquemas de organización en el sitio permite identificar conceptos que se repiten en cada muestra e incluso detectar las partes de la estructura donde dichos conceptos se ubican.

Los conceptos encontrados en el dominio de sitios Web de educación se describen en

el diccionario del anexo A, aunque cabe aclarar que no son los únicos términos encontrados, sino aquellos que se tomaron por su continua aparición.

Capítulo 3. Estado del Arte

Este capítulo se enfoca en hacer una descripción de los trabajos y encontrados en la literatura que se asemejan en ciertas características a la propuesta descrita en capítulos posteriores. Estos trabajos sirven como un marco de referencia que ayuda a delimitar la investigación y a encontrar aspectos de mejora que se toman en cuenta al momento de llevarla a cabo.

Capítulo 3. Estado del arte

Página 21

3.1. WebTOC

WebTOC [Plaisant 1997] es una herramienta elaborada en Java que permite visualizar el contenido de un sitio Web. La visualización se lleva a cabo a través de una tabla jerárquica que organiza el contenido. Consta de dos partes:

1) Parser: analizador sintáctico que genera una tabla de contenidos (TOC7) para

representar el sitio.

2) Interfaz de usuario: un Applet de Java que muestra el TOC y proporciona interacción

dentro de un navegador convencional.

Figura 3.1. Ejemplo de aplicación de WebTOC

Fuente: ftp://ftp.cs.umd.edu/pub/hcil/Demos/WebTOC/Paper/WebTOC.html

Cada línea de texto del TOC representa un enlace a un documento, ya sea una página Web o un archivo multimedia. En la parte superior izquierda de la figura 3.1 se observa un panel de control con una barra de colores que representan cuatro tipos de elementos del sitio: texto, imagen, audio y otros. Debajo de la barra de colores hay una escala para indicar el tamaño de los archivos que inicia con 1kb (1000 bytes).

En la parte inferior izquierda de la figura 3.1 se despliega el TOC del sitio. Una barra a

la derecha de cada etiqueta de la jerarquía indica los tipos de archivos (tomando en cuenta la barra de colores) y su tamaño.

7 Tabla de Contenido, por sus siglas en inglés.


Página 22

Para generar automáticamente la tabla de contenidos primero se limita el análisis a los enlaces locales del sitio Web8. Existe también una opción para mostrar enlaces externos en el WebToc, sin indicar el tamaño o tipo de documentos. Posteriormente, el analizador sintáctico genera un archivo con formato similar al HTML, que contiene información del servidor e indica el inicio y fin de un grupo de enlaces e información sobre cada documento o enlace. El archivo creado tiene una extensión “.hdir”.

3.2. DreamWeaver

Dreamweaver versión 8.0 [Adobe 2007] es un editor HTML profesional para diseñar, codificar y desarrollar sitios, páginas y aplicaciones Web. Trabaja en un entorno de codificación HTML manual y en un ambiente visual. Esta herramienta ofrece entornos de codificación de otras funciones. Incluye elementos para la edición de código y material de referencia sobre HTML, CSS, JavaScript, ColdFusion Markup Languaje (CFML), Microsoft Active Server Pages (ASP) y JavaServer Pages (JSP). Además, Dreamweaver permite visualizar la carpeta local de un sitio en forma de mapa visual de íconos vinculados, denominado mapa del sitio. Los mapas del sitio sirven para añadir nuevos archivos a un sitio de Dreamweaver y para agregar, modificar o eliminar vínculos.

3.2.1. Visualización del mapa del sitio

Para ver el mapa del sitio, se define primero una página principal, que puede ser cualquier página del sitio Web. No es necesario que sea la página inicial, pues ésta es sólo el punto de partida del grafo. La herramienta proporciona un menú que muestra el sitio, el servidor o la unidad actual. Luego se selecciona un archivo para que sea convertido en la página principal. Dreamweaver señala cada elemento del mapa del sitio con colores:

Texto en rojo: indica un vínculo roto.

Texto en azul y marcado con un icono de globo terráqueo: indica un archivo de otro

sitio o un vínculo especial (por ejemplo, un correo electrónico o script).

Marca de verificación verde: indica un archivo protegido por el autor.

Marca de verificación roja: indica un archivo protegido por otro usuario.

Ícono de candado: indica un archivo de sólo lectura (Windows) o bloqueado

(Macintosh).

8 WebTOC sigue los enlaces o nombres de directorios para construir un árbol jerárquico del sitio.


Página 23

Trabajar con un mapa de sitio permite seleccionar páginas, abrirlas para editarlas, añadir nuevas páginas al sitio, crear vínculos entre archivos y cambiar títulos de páginas. Incluso pueden observarse detalles de una sección específica de un sitio al convertir una rama en el centro del mapa del sitio.

3.3. SGMapper

SGMapper [Liechti 1998] es una herramienta que utiliza metadatos SGF9 para generar mapas de sitio interactivos. Los grafos estructurados proporcionan navegación escalable y la posibilidad de editar grafos grandes. Brindan además una distinción entre enlaces jerárquicos y asociativos. Estos dos tipos de enlaces se denominan explícitos. También se crean enlaces asociativos implícitos para mostrar asociaciones entre subjerarquías.

3.3.1. Organización jerárquica del sitio Web

Un sitio Web puede organizarse como una jerarquía en base a metadatos SGF. Esta organización refleja relaciones de agregación y proporciona facilidad de exploración. Posteriormente los datos se envían a un servidor y se muestran en SGMapper.

El usuario selecciona un nodo para expandir la jerarquía. Si un usuario presiona dos veces un nodo, la URL correspondiente se descarga y se muestra en el navegador.

3.3.2. Organización de red del sitio Web

La relación asociativa define la estructura de red de un sitio Web. Explorar una estructura de red tendría los mismos resultados que explorar una jerarquía.

3.3.3. Enlaces asociativo implícito

Sean A y B dos subjerarquías con, por lo menos, un enlace asociativo explícito entre dos elementos a y b, donde a pertenece a A y b pertenece a B, se dice que existe una relación asociativa implícita entre A y B.

9 Formato de Grafo Estructurado, por sus siglas en inglés.


Página 24

3.3.4. Formato SGF

Para describir el sitio Web se utiliza el formato SGF, que ayuda a codificar la información.

Existe una especificación SGF, en la forma de una DTD10 XML usada para codificar metadatos de nodos y enlaces. La DTD contiene restricciones para una clase de documento. Algunas de las restricciones válidas del formato SGF se muestran a continuación, de manera breve:

El sitio Web se captura como un grafo estructurado. La raíz de un documento SGF debe ser un elemento del tipo grafo estructurado. Un elemento del tipo grafo estructurado puede tener un número arbitrario de

subelementos, seguidos por subelementos de tipo nodos, jerarquías y redes. Los elementos nodo pueden tener un número arbitrario de elementos nodo. Los elementos de tipo jerarquía pueden tener un número arbitrario de enlaces. Los elementos de tipo red pueden tener un número arbitrario de enlaces

Un elemento nodo debe tener un identificador único. Un elemento nodo puede tener un atributo de etiqueta. Un elemento nodo puede tener un número arbitrario de subelementos. Un enlace debe tener un atributo de fuente, para el cual debe existir un identificador

único. Un enlace debe tener un atributo de destino, para el cual debe existir un identificador

único. Un enlace puede tener un atributo de etiqueta. Un enlace puede tener un número arbitrario de subelementos. Un subelemento debe tener dos atributos: nombre y valor.

El uso de subelementos hace extensible al SGF, permitiéndole la adición de

información específica de la aplicación.

3.3.5. Implementación

La herramienta cliente necesita tres elementos: un navegador Web estándar para acceder a la información en la Web, un visor interactivo para realizar el análisis de los documentos SGF y visualizar la estructura del sitio y un programa espía que pueda realizar la comunicación entre los dos anteriores. La comunicación se lleva a cabo por medio de mensajes.

El comportamiento del sistema se describe en la figura 3.2.

10

Descripción de Tipo de Documento, por sus siglas en inglés.


Página 25

Figura 3.2. Funcionamiento del cliente

1) El espía manda un mensaje de eco para recibir como respuesta otro mensaje cuando

una URL sea descargada por el navegador. 2) El espía manda un mensaje para indicar que soporta archivos SGF y así el recurso sea

descargado. 3) El recurso es traído desde el navegador. 4) El navegador avisa al espía que se ha descargado una URL y manda el tipo MIME

para ser verificado en el espía. 5) Se verifica que sea un tipo SGF. 6) El documento SGF es traído por el navegador y éste lo almacena en disco, enviando

una solicitud al espía para que lo abra. 7) Cuando el navegador ha enviado el documento al espía, éste manda los metadatos al

visor para mostrarlos. 8) Cuando un usuario presiona dos veces sobre un nodo del visor, este último alerta al

espía. 9) El espía le solicita al navegador descargar la URL correspondiente. 10) El recurso finalmente es traído y mostrado en el navegador.

Del lado del servidor sólo debe cuidarse que el documento SGF exista en el servidor y

sea accesible al menos por un hipervínculo y que cuando se mande este documento al cliente, el servidor especifique explícitamente que es un documento SGF.

3.4. UriGraph

UriGraph es un modelo de estructuración de sitios Web que especifica la identidad, identificador, posición y composición de cada recurso que constituye el sitio Web [Simic 2002].

Identidad: intención del concepto representado. Conjunto de los atributos que definen al concepto

Identificador: representado por la URI. Debe comunicar la información de la identidad del recurso.


Página 26

Composición: cada recurso Web se compone de varias partes o componentes de recurso.

Posición: define las relaciones de un recurso con otros componentes de ese sitio.

El modelo Urigraph [Simic 2003] utiliza análisis de URI a través de un grafo dirigido. Este modelo se divide en tres capas, descritas a continuación.

3.4.1. Capas del modelo Urigraph

1) Capa topológica

Figura 3.3. Ejemplo de la capa topológica de

UriGraph

Fuente: [Simic 02]

Define un grafo G=(V,E) donde:

V = {conjunto de n nodos | v1 hasta vn Є V} E= {conjunto de aristas ≠ V} Existe una relación binaria entre V y E. Hay dos tipos de nodos: P= {conjunto de nodos sitio} T= {conjunto de nodos transición} ∃(r) | r= nodo raíz análogo a la página principal del grafo dirigido. ∀(v) ∃( Dv) | (v Є V)^es(Dv , conjunto de nodos destino)

Para cada nodo v existe un conjunto de nodos destino Dv que consiste en todos los

nodos conectados al nodo v a través de sus aristas salientes.


Página 27

Los nodos sitio son representados por círculos. Los nodos transición se representan como rectángulos anchos y las aristas como flechas. El nodo raíz se marca con el símbolo de una casa (figura 3).

Los nodos sitio simbolizan clases de recursos que contienen uno o varios recursos

similares que difieren en contenido, pero no en el modo en que son representados en el sitio. El nodo raíz es la página principal del sitio y los nodos transición marcan el análisis de piezas de información.

Los términos básicos de la topología son:

Camino: secuencia de nodos donde dos nodos consecutivos se conectan con una arista en la misma dirección.

Pasaje: camino que comienza en el nodo raíz y termina con un nodo sitio. Circuito: camino que comienza y termina en el mismo nodo.

Los casos de conexiones imposibles se muestran a continuación:

Las conexiones no son reflexivas: un nodo no se conecta consigo mismo. No hay conexión directa de dos nodos sitio. Una transición sólo puede tener una arista de salida a un nodo sitio, como máximo.

2) Capa de análisis de solicitud

Capa intermedia que define las reglas para analizar el identificador del recurso. El identificador del recurso distingue dos partes de la URI, la ruta y la solicitud, por lo que la capa intermedia aloja dos secuencias, una secuencia de segmentos de ruta y una secuencia de segmentos de solicitud (figura 3.4). El análisis del identificador inicia en el nodo raíz con un contenedor lleno de todos los segmentos de la solicitud HTTP y sigue las aristas a través de los nodos. El análisis termina regularmente en algún nodo sitio con un contenedor vacío, así se construye un pasaje en el grafo. Si el análisis termina en un nodo transición se considera la solicitud como incompleta y el análisis es insatisfactorio.


Página 28

Figura 3.4. Estructura de la URL en Urigraph

3) Capa de síntesis de respuesta

La capa más alta de la arquitectura, define cómo la información es extraída de la solicitud e integrada en la respuesta. La respuesta contiene la identidad y composición del recurso identificado por la solicitud. La información de respuesta no es gráfica.

3.4.2. Gramática XML

La gramática XML se usa para descripciones y consiste en una estructura de elementos que encierra nodos sitio, transiciones de ruta y transiciones de solicitud. Estos elementos ayudan a representar varios tipos de nodos. Cada nodo posee un identificador usado para conectar un subelemento connectTo. Un ejemplo de la gramática para la figura 3.4 se muestra a continuación.

Figura 3.5. Gramática XML de Urigraph


Página 29

3.5. CmapTools

El software CmapTools [IHCM 2007] se desarrolló en el IHMC11 y proporciona el uso de mapas conceptuales, particularmente en la WWW. Permite crear mapas de conceptos para organizar contenidos y colaborar con la creación de mapas a distancia. Utiliza una arquitectura cliente/servidor. Los usuarios comparten sus mapas en un servidor.

CmapTools permite disponer grandes cantidades de documentación (imágenes, texto, videos y páginas Web) de tal forma que el acceso sea fácil, a través de la navegación de mapas conceptuales sobre un tema determinado.

Los mapas conceptuales son una opción ante el problema de los usuarios para encontrar un modelo de organización de páginas o no conocer el contenido de las páginas a las que tendrán acceso con ciertos enlaces. Esto se debe a que, al seleccionar las ligas o enlaces, el usuario frecuentemente no tiene idea de cuál será el contenido de la página destino.

CmapTools utiliza los conceptos de modelos conceptuales, tales como nodos que se enlazan con relaciones. Estos enlaces están etiquetados. En cada nodo o concepto del mapa, el usuario dispone de un menú de íconos. Éstos corresponden a diversos medios (texto, imágenes, video, otros mapas conceptuales, etc.) relacionados al tema del nodo (concepto) seleccionado. Al seleccionar un icono, el sistema despliega información de otros recursos referentes al concepto.

Los íconos aparecen en diversas combinaciones dependiendo de la información disponible sobre el concepto dado. Todas las ligas tienen semántica definida por el diseñador del sitio, ya sea explícita en el mapa o por contexto al navegar entre mapas u otros medios. El usuario sabe entonces hacia dónde va cuando sigue una liga, en contraste con otras herramientas de navegación, especialmente en la WWW.

Para construir los mapas se usa un editor. El usuario relaciona los medios (video, imágenes, sonido, mapas, entre otros) y sus iconos con los nodos (conceptos). Aprovechando la extensión y omnipresencia de Internet, se construyen sistemas de multimedia accesibles desde cualquier lugar del mundo. El programa está escrito en Java y se ejecuta en cualquier plataforma computacional (Windows, Macintosh, UNIX, etc.)

Existen herramientas similares a CmapTools, tales como:

View Your Mind12

DeepaMehta13

11 El Instituto para la Cognición Humano y Máquina es una institución de investigación sin fines de lucro del

Sistema de Universidades de Florida. 12

Página oficial del software View Your Mind: http://www.insilmaril.de/vym/


Página 30

Estas herramientas no se reportan debido a que sus características no varían en comparación con CmapTools.

3.6. OOWS (Método de Producción de Soluciones Web Orientado a Objeto)

El Método OOWS [Fons 2002] es una extensión del Método OO para la generación automática de código usando modelos conceptuales, que se basa a su vez en OASIS14. OOWS permite capturar y representar la semántica de navegación y de presentación de la información por medio de primitivas de abstracción de alto nivel. Posteriormente conforma un repositorio de requisitos básicos de construcción, procesados con la finalidad de generar interfaces de usuario.

Figura 3.6. Aproximación a la metodología OOWS

El modelado del sistema con OOWS abarca dos pasos: la especificación del problema

y el desarrollo de la solución.

3.6.1. Especificación del problema

Comprende la captura del comportamiento que satisface los requisitos de los usuarios identificados.

13

Página oficial del software DeepaMehta: http://www.deepamehta.de/ 14

Por sus siglas en inglés, Especificación Abierta y Activa de Sistemas de Información. Es un enfoque formal

para la especificación de modelos conceptuales siguiendo el paradigma orientado a objetos.


Página 31

En la especificación del problema se desarrolla la fase del Modelado Conceptual que divide su operación en los siguientes modelos [Fons 2002]:

A) Modelo semántico: se define la estructura del sistema (clases, operaciones y atributos)

y las relaciones estructurales entre clases por medio de un Diagrama de Clase. B) Modelo dinámico: captura las interacciones entre objetos.

C) Modelo funcional: toma la semántica de cambios de estado.

La parte complementaria al Método OO integra dos modelos:

D) Modelo de Navegación: proporciona a los usuarios acceso a la información y la

funcionalidad para llevar a cabo sus tareas dentro del sistema y las secuencias de

caminos que deben seguir para conseguirlo.

Se compone de un conjunto de mapas de navegación cuya función es representar la visión global del sistema para cada tipo de usuario, definiendo su navegación permitida. Éste se representa usando un grafo dirigido donde los nodos son los contextos de navegación y los arcos son enlaces de navegación.

Un contexto de navegación es una unidad de interacción abstracta que representa una vista sobre un conjunto de datos y servicios accesible para un usuario en un determinado momento. Está compuesto por un conjunto de clases de navegación haciendo referencia a las clases identificadas en el modelo de objetos, con las que se define la visibilidad ofrecida al agente en ese nodo.

E) Modelo de presentación: cuando el modelo de navegación captura la semántica de

navegación del sistema, se asocian características de presentación al mismo. El modelo

de presentación complementa la información capturada en el modelo de navegación

para crear las interfaces con información de presentación.

Tras el modelado, se genera el código basándose en la recopilación de requisitos, por medio del compilador de modelos conceptuales (model compiler) que, en función de patrones arquitectónicos y dependiendo de la plataforma destino, construye el sistema de software que recoge los requisitos de aplicación modelada.

El Método OO maneja diferentes tipos de relaciones que son correspondientes a

algunas relaciones de UML [Insfrán 1998].

1) Agregación, también conocida como “parte de”: relación jerárquica en la que el concepto de nodo padre es más amplio que el de los nodos hijo. La relación de agregación es no reflexiva, no simétrica y transitiva.

2) Herencia, también conocida como “es un”. A) Especialización: trata la herencia descendiente o derivación de clases hijas a

partir de una clase padre.


Página 32

B) Generalización: es la inversa de la especialización. Tratar la herencia ascendente o generación de clases (padre) a partir de propiedades comunes de clases definidas (hijas) con anterioridad.

3) Agentes: relación entre objetos cliente y servidor.

3.7. Touch Graph

TouchGraph [TouchGraph 2007a] es una herramienta realizada en Java para visualización de redes de información relacionadas entre sí, mostrando grafos interactivos. Por medio de una imagen visual, un usuario puede navegar a través de redes de gran tamaño. La solución de visualización propuesta permite mostrar relaciones entre personas, organizaciones e ideas.

El proyecto TouchGraph se divide en dos modalidades, propietario y de código abierto, presentadas a continuación.

3.7.1. TouchGraph propietario

Integra visualización gráfica de componentes tradicionales de tablas y árboles para descubrir información, proveyendo soluciones ad-hoc a las necesidades de empresas y compañías. La plataforma permite el acceso a cualquier fuente de información conectado o no conectado a internet, así como la generación de reportes en hojas de cálculo o imágenes en archivos PDF.

El sitio Web muestra el funcionamiento de TouchGraph en un navegador de demostración para el sitio Amazon, un navegador para la visualización de redes sociales aprovechando la plataforma de Facebook15 y una aplicación para explorar conexiones entre sitios relacionados usando datos obtenidos de Google .

3.7.2. TouchGraph de código abierto

La idea de TouchGraph fue concebida por Alex Shapiro, como una combinación de elementos de herramientas de visualización propietarias como inXigth y TheBrain, usando el lenguaje Java bajo el sistema CVS16.

A continuación se analizarán dos de las aplicaciones relevantes contenidas en el repositorio.

15

Facebook es un sitio Web de redes sociales (estructuras sociales representadas por grafos donde los nodos son

individuos y las aristas las relaciones entre ellos). Página oficial de Facebook: http://www.facebook.com/ 16

Sistema de control de versiones, por sus siglas en inglés: mantiene el registro de los trabajos y cambios en los

ficheros que forman un proyecto y permite la colaboración entre desarrolladores.


Página 33

3.7.2.1. LinkBrowser

Grafica desde archivos XML (TG-XML) Genera grafos y los almacena en archivos TG-XML.

A) Inclusión de Hints (información adicional) de los nodos

Figura 3.7. Ejemplo de Hint

Los nodos pueden contener información adicional como archivos HTML, hiperenlaces

o imágenes. La información de cada nodo aparece en marcos internos. La información adicional de cada nodo puede desplegar archivos HTML externos

mediante el uso de marcos.

B) Uso de URL´s

Los nodos pueden tener URL´s asociadas, que actúan al seleccionar un nodo y presionarlo.

Las URL´s pueden marcarse como locales o remotas. Una URL local no necesita usar el prefijo “http://” y las páginas asociadas pueden cargarse en un marco interno. Las URL´s remotas aparecen por separado en una ventana de navegador distinta.

Las URL´s pueden marcarse como archivos XML. Cuando se presiona un nodo, se lee un archivo TG-XML y se carga el grafo que éste especifica.

Se proporciona un botón de retorno para volver a un archivo TG-XML cargado previamente.


Página 34

3.7.2.2. WikiBrowser

TouchGraph WikiBrowser [TouchGraph 2007b] es una demostración de cómo TouchGraph puede usarse para visualizar una wiki. Actualmente la versión de prueba presenta las bases de datos de enlaces Meatball Wiki y EmacsWiki, pero ninguna otra base de datos codificada en un formato similar puede mostrarse.

Por ahora, la herramienta es una versión de prueba debido a que la base de datos de enlaces no se actualiza dinámicamente mientras se navega o carga desde una URL antes de activar la visualización. Para solucionarlo se plantea adquirir la estructura de enlaces por medio de una API basada en XML.

Las bases de datos de enlaces proporcionan una lista de todos los enlaces de páginas de una wiki local. El primer enlace en cada línea es la página que está siendo buscada y los siguientes enlaces son aquellos que fueron encontrados en dicha página. WikiBrowser es capaz de crear un grafo a partir de las bases de datos de hiperenlaces.

La aplicación consta de un navegador HTML convencional en la parte izquierda y un grafo en el lado derecho de la pantalla. Las etiquetas del nodo corresponden a las páginas de hipertexto, conectadas por enlaces que representan los hiperenlaces entre las páginas. Los nodos de color café muestran hiperenlaces de páginas internas de la wiki y los púrpura simbolizan a las páginas externas.

3.8. PersonalBrain

PersonalBrain [Brain 2007] es un software desarrollado por medio de la tecnología de modelado de información llamada “The Brain”, que funciona bajo la idea de que la información se almacena del mismo modo en que el cerebro lo hace, de manera intuitiva, con asociaciones entre los pensamientos que están contenidos ilimitadamente en el cerebro.

PersonalBrain usa como bloque básico de construcción un formato de dato llamado pensamiento (thought). Los pensamientos pueden ser un tipo de información cualquiera, como conceptos, proyectos, personas, materias, documentos, páginas Web, etc.

La herramienta permite crear enlaces y asociaciones entre los pensamientos, formando

una interfaz visual que refleja estas asociaciones en un grafo. Un cerebro no es una estructura jerárquica, ningún pensamiento es más importante que otro, por ello el usuario puede representar el modo en que se relacionan y lo que contienen.

3.8.1. El pensamiento activo

Al centro de PersonalBrain hay un pensamiento activo que representa el concepto central sobre el que se dibuja una serie de pensamientos relacionados en diferentes zonas.


Página 35

Las zonas son áreas que manejan relaciones específicas del pensamiento central. Hay cuatro zonas: la zona de padres, la zona de hijos, la zona de saltos y la zona de hermanos.

3.8.2. Relaciones de pensamientos

La idea de PersonalBrain es crear y mostrar relaciones entre tipos de información. Las relaciones se construyen creando y ordenando pensamientos hijos, padres y saltos. Los nombres de las relaciones no tienen relación con el tipo de información que pueden contener, solamente describen su asociación con el pensamiento activo y las relaciones entre ellos.

Hay cuatro tipos de relaciones entre pensamientos: padre, hijo, salto y hermano [Brain 2004].

Figura 3.8. Tipos de pensamiento

Padre: un pensamiento padre tiene al menos un pensamiento debajo de él, es desplegado en la zona de padres, directamente sobre el pensamiento activo. Un pensamiento puede tener múltiples padres (un máximo de 32).

Hijo: es una subcategoría de un pensamiento activo. Varios pensamientos pueden compartir un padre. El máximo número de pensamientos hijos que puede tener un padre es de 128.

Hermano: un pensamiento hermano comparte el mismo padre que un pensamiento activo. Los hermanos son parte de un grupo cuya fuente de temas es el pensamiento padre.

Salto: un pensamiento de salto se relaciona con el pensamiento activo, pero no es una subcategoría. Los saltos se usan para crear relaciones entre grupos de pensamientos que están desplegados en la zona de salto. El máximo número de pensamientos de salto es de 32.

Los nodos se organizan en zonas: la zona de padres está sobre el pensamiento activo,

la zona de hijos debajo de él, la zona de saltos a la izquierda y la zona de hermanos a la derecha.


Página 36

Los pensamientos están relacionados de manera directa o indirecta en virtud de que pertenecen al mismo cerebro, donde el cerebro es el conjunto que contiene a los pensamientos y sus enlaces. No hay reglas que gobiernen la creación de relaciones entre pensamientos.

3.9. OntoWebber

Esta herramienta [Jin 2001] adopta el modelo-dirigido de aproximación basado en ontologías para el manejo de sitios Web declarativos e integración de datos. Al mismo tiempo ofrece soporte a través del ciclo de vida del sitio Web, que incluye diseño, generación, personalización y mantenimiento. La idea fundamental detrás de OntoWebber es el uso de ontologías como la base de construcción de diferentes modelos necesarios para la creación de un sitio Web.

Su arquitectura se descompone en cuatro capas:

Capa de integración: resuelve las diferencias sintácticas entre datos heterogéneos

distribuidos en varias fuentes.

Capa de articulación: resuelve las diferencias semánticas entre las fuentes de datos.

Capa de composición: las ontologías para un modelo de un sitio son un conjunto de

esquemas predefinidos, disponibles en un repositorio central. Una vista del sitio

particular consiste en un conjunto de páginas Web que pueden ser creadas a partir de

datos señalados. La especificación de una vista del sitio es un conjunto de modelos de

sitios encargados de describir distintos aspectos de una vista del sitio basada en las

ontologías de modelado del sitio. Esta vista se exporta al motor de solicitudes.

Capa de generación: un sitio navegable puede generarse instanciando la vista del sitio

correspondiente, con datos en el repositorio. Esto se lleva a cabo con el motor de

solicitud.


Página 37

Tabla 3.1. Comparación de herramientas del estado del arte

Característica

Herramienta

Representar la estructura del

sitio Web

Permitir creación o edición de

representaciones gráficas del sitio

Relacionar semánticamente el grafo del sitio

Web

Establecer reglas en el

formato para los elementos

de la representación

gráfica

Proporcionar restricciones de construcción del

sitio Web

Generar archivo XML u otro formato de estructura

validada del grafo

Generar las páginas de la estructura del sitio Web de

forma automática

Disponibilidad de la herramienta

WebTOC Si No No Si No No No Software de código abierto

Dreamweaver Si Si No Si No No No Software propietario

SGMapper Si Si No No No Si No No disponible

UriGraph Si No No No No Si Si No disponible

CmapTools Si Si Si No No No No Software de distribución

gratuita con código cerrado

gOOWS Si No No No No No Si Software de código cerrado

TouchGraph Si Si No No No Si No Software con versiones de código

abierto y cerrado Personal Brain Si Si No No No No No Software de

distribución gratuita con código

cerrado OntoWebber Si No No No No Si Si Software de código

abierto Herramienta

propuesta Si Si Si Si Si Si Si Software de código

abierto

Capítulo 4. Análisis y diseño de la solución

El presente capítulo describe la solución propuesta a la problemática estudiada en este trabajo. Se detalla la investigación realizada para encontrar los patrones, conceptos y relaciones que conforman la ontología del dominio de educación que se utiliza en la metodología para la construcción de sitios Web.


Página 39

4.1. Descripción general de la solución propuesta

La solución que se plantea para la presente investigación se describe a continuación.

Se propone como hipótesis que a través de una metodología de construcción de sitios Web basada en principios de ontologías, se pueda agregar semántica a la estructura del sitio para que éste sea más fácil de comprender. El proceso de solución se compone de tres fases:

a) El análisis de un caso de estudio (una muestra de sitios Web de escuelas y centros de

investigación)

b) La definición y formalización de la metodología de construcción del sitio Web,

c) La implementación de un editor de estructuras de sitios Web, basado en la

metodología propuesta. El editor debe permitir al arquitecto establecer los tipos de

relaciones entre los elementos que constituyen el sitio, de tal manera que se asegure el

cumplimiento de las pautas de construcción proporcionadas por la metodología.

Dichas pautas dependen del tipo de relación establecida inicialmente.

4.2. Desarrollo de una metodología para definir estructuras de sitios Web basada en diseño de ontologías

La metodología de solución propuesta requirió de un trabajo de investigación con un análisis de sitios Web del dominio de educación. Aunque se trabajó sobre un dominio específico, se espera que esta propuesta sea adaptable y pueda aplicarse a otros dominios de sitios Web.

Los pasos a seguir que conforman dicha metodología se listan a continuación y se

explica la manera en que se realizaron.

4.2.1. Estudio de los dominios de trabajo

4.2.1.1. Análisis de sitios Web de dominio educación (edu)

Para llevar a cabo el análisis de dominio del tipo académico se seleccionó una muestra de sitios en base a un valor de agrupación. Originalmente se deseaba tomar como valor el tamaño de la población estudiantil, sin embargo, no fue posible utilizar este dato ya que no es público. Como una segunda opción se eligió el tipo de institución educativa, tomando en consideración dos tipos: institutos tecnológicos y centros de investigación. A pesar del factor de selección anterior, se limitó la muestra a veinte sitios de este tipo, por la amplitud del dominio de trabajo.


Página 40

A partir del análisis anterior se obtuvieron los modelos de organización, tipos de enlaces y patrones que sigue la estructura de los sitios Web, para utilizarlos en la formalización de una ontología, como base para la definición de la metodología, y el diseño del editor que la implemente. A continuación se muestra cada paso del análisis realizado.

Conjunto de instituciones analizadas

La siguiente tabla muestra el conjunto de sitios Web que se estudiaron dentro del dominio de educación.

Tabla 4.1. Conjunto de sitios Web analizados

No. Nombre de la institución Página Tipo de sitio

1 Centro de Investigación Científica y de Educación Superior de Ensenada (CICESE)

http://www.cicese.mx/ Centro de Investigación

2 Centro de Investigación en Computación, IPN

http://www.cic.ipn.mx/

Centro de Investigación

3 Centro de Investigación en Matemáticas, A. C.

http://www.cimat.mx/

4 Centro de Investigación y Asistencia en Tecnología y Diseño del estado de Jalisco (CIATEJ)

http://www.ciatej.net.mx/ Centro de Investigación

5 Centro de Investigaciones Biológicas del Noroeste, S. C. (CIBNOR)

http://www.cibnor.mx/ecibnor.php Centro de Investigación

6 Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional (CINVESTAV)

http://www.cinvestav.mx/ Centro de investigación

7 Centro de Investigación y Docencia Económicas (CIDE)

http://www.cide.edu/ Centro de investigación

8 Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)

http://www.cenidet.edu.mx Centro de investigación

9 División Académica de Economía, Derecho y Ciencias Sociales, ITAM

http://daedcs.itam.mx/

Centro de Investigación

10 Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE)

http://www.inaoep.mx Centro de investigación

11 Instituto Tecnológico de Acapulco (ITA)

http://www.it-acapulco.edu.mx Instituto Tecnológico

12 Instituto Tecnológico de Apizaco

http://www.itapizaco.edu.mx Instituto Tecnológico

13 Instituto Tecnológico del Altiplano de Tlaxcala

http://italtiplanotlaxcala.edu.mx Instituto Tecnológico


Página 41

14 Instituto Tecnológico de Celaya (ITC)

http://www.itc.mx/itc/scripts/index. Php

Instituto Tecnológico

15 Instituto Tecnológico de Chihuahua

http://www.itchihuahua.edu.mx/ Instituto Tecnológico

16 Instituto Tecnológico de Chilpancingo (ITCHILPANCINGO)

http://www.itchilpancingo.edu.mx/ principal/servlet/hinicio

Instituto Tecnológico

17 Instituto Tecnológico de Ciudad Madero

http://www. itcd.edu.mx/ Instituto Tecnológico

18 Instituto Tecnológico de Minatitlán (ITMINA)

http://www.itmina.edu.mx Instituto Tecnológico

19 Instituto Tecnológico de Morelia

http://www.itmorelia.edu.mx Instituto Tecnológico

20 Laboratorio Nacional de Informática Avanzada (LANIA)

http://www.lania.mx Centro de Investigación

Tras analizar la muestra de sitios Web se encontró que presentaban semejanzas en el

tipo de conceptos y estructuras, por lo que no se consideró necesario extender el análisis a más sitios, sobre todo por limitaciones de tiempo.

4.2.1.2. Estructura de páginas

Los sitios Web incluyen varios sistemas de navegación definidos en el capítulo 2. La identificación de los sistemas de navegación permite conocer la estructura del sitio, separando los componentes de tipo jerárquico y de hipertexto que se encuentran en las páginas.


Página 42

Figura 4.1. Página principal del CINVESTAV

Dentro de las páginas principales de la mayoría de los sitios se observaron conjuntos

de enlaces concentrados en tres grupos (figura 4.1).

A) Conjunto primario de navegación:

Este conjunto está conformado por elementos descriptivos y de organización, como: información sobre la institución, accesos a la oferta educativa (posgrados o carreras) y líneas de investigación, así como organigramas de los departamentos de la institución.


Página 43

Figura 4.2. Ejemplo de estructura jerárquica entre la página principal del CINVESTAV y elementos del

grupo de navegación primario

B) Conjunto secundario de navegación:

Constituido de enlaces hacia eventos, noticias o cursos. En este conjunto aparecen las convocatorias para cursar estudios en las instituciones educativas, enlaces a talleres y congresos, enlaces de interés y otras actividades.

Figura 4.3. Enlaces del conjunto secundario de navegación


Página 44

C) Conjunto terciario de navegación

Conformado por enlaces hacia el correo institucional, mapa del sitio, página principal, encuestas y buscadores, entre otros.

4.2.2. Construcción de una ontología del dominio de educación

Del análisis anterior se obtuvieron patrones de cómo los elementos se distribuyen en los sitios Web. Los patrones pueden formalizarse en una ontología que permita catalogar los conceptos en clases y definir las relaciones entre las clases y las instancias correspondientes a las clases. Éstas se mapean directamente como las páginas que forman la estructura del sitio Web.

4.2.2.1. Identificación del propósito de la ontología

Los sitios Web poseen un vocabulario específico, de acuerdo al dominio al que pertenecen, siendo en este caso el dominio de educación (Dominio de nivel superior EDU). Sin embargo y, a pesar de que existen conceptos comunes entre los sitios analizados, es también frecuente encontrar sinónimos o términos que varían de acuerdo al tipo de institución educativa, debido a cuestiones propias del idioma.

Lo anterior deriva en definiciones del vocabulario de la estructura del sitio poco consistentes y en el establecimiento de nexos existentes entre los conceptos del dominio que no expresan la naturaleza de la relación. Es por ello que resulta importante reducir los problemas de comprensión de la estructura del sitio Web.

Para eliminar estas ambigüedades se requiere:

Identificar los conceptos propios del dominio de trabajo que son utilizados por los

usuarios y proporcionar un vocabulario compartido, disminuyendo las diferencias y

confusión de terminología utilizada para denominar a los elementos que conforman el

sitio Web.

Identificar las posibles relaciones entre los conceptos del dominio.

Brindar restricciones que puedan ser aplicadas al contexto que integran los conceptos

y relaciones que los enlazan, así como sus sinónimos correspondientes.

4.2.2.2. Identificación de conceptos del dominio

En este apartado se identifican los conceptos y las relaciones en el dominio de educación. Posteriormente se producen las definiciones no ambiguas para los conceptos. Una definición no ambigua permite diferenciar los conceptos, evitando la confusión de términos o interpretaciones erróneas.


Página 45

4.2.2.3. Creación de la taxonomía de clases

Los conceptos obtenidos del dominio de trabajo pueden organizarse hasta obtener una taxonomía que los agrupe en clases y subclases, descartando aquellos elementos que son propiamente las instancias. Finalmente la taxonomía de clases de la ontología se muestra en la figura 4.4 y se describe posteriormente cada una, listando algunos tipos de instancias.

Figura 4.4. Diagrama de clases de la ontología

En la tabla 4.2 se definen las clases de la taxonomía generada para el dominio de educación del caso específico analizado en esta investigación (la identación indica una relación de clase-subclase). Aunque sólo las clases correspondientes a las hojas de la taxonomía son tomadas en cuenta para la especificación de relaciones entre conceptos del dominio.

class Class Model

Documento

+ Conectividad: char

+ Temporalidad: char

+ TipoEntidad: char

InformaciónProductoServ icio

Serv icio interno Serv icio externo Estructura

Unidad

organizacional

Organización

funcionamiento

Descripción Trámite Suceso Personal

Estudiante TrabajadorDescripción

física

Descripción

abstracta


Página 46

Tabla 4.2. Definición de clases de la taxonomía

Documento: un documento es la clase más genérica, es decir, a partir de ella se desprenden las demás clases de la ontología. El documento representa cualquier tipo de elemento que pueda conformar un sitio Web, por ejemplo: una página html, una imagen gif o un archivo de texto pdf.

Información: documento para compartir o difundir datos.

Descripción: proporcionan al usuario un panorama general de la institución.

DescripciónAbstracta: un documento de descripción se refiere a elementos de presentación de la institución. Pueden contender detalles históricos, definición del perfil de la institución, objetivos, etc.

DescripciónFísica: elemento que muestra la disposición de los recursos de una institución.

Estructura: documentos referentes a la manera en que se conforma la institución organizacionalmente.

OrganizaciónFuncionamiento: muestra la administración o coordinación de un proceso de manera formal.

UnidadOrganizacional: espacio de trabajo o unidad administrativa de la institución. Se identifica por las funciones que lleva a cabo, el conjunto de responsabilidades que asume o por identificar a una agrupación.

Personal: tipo de documento que contiene información sobre una entidad animada.

Estudiante: dentro de la clase Personal, la cual aloja información sobre un estudiante de la institución educativa.

Trabajador: dentro de la clase Personal, la cual aloja información sobre un empleado de la institución educativa.

Trámite: indica la consecución de pasos para desarrollar una tarea de interés para los estudiantes o el personal de la institución. Los trámites suelen ser actividades obligatorias.

Suceso: documento informativo cuyo tiempo de vida tiene una duración establecida. Se refiere a aquellos componentes que no son permanentes y viven mientras poseen carácter de importancia en el sitio web o en una temporada específica con respecto a un acontecimiento relevante.

Producto: representa un objeto que percibe un consumidor o un conjunto de beneficios o satisfacciones. En los centros de investigación, los productos son el resultado de la investigación científica.

Servicio: describe procesos, algunas veces dinámicos, que requieren introducción de datos por parte del usuario para obtener como resultado un componente que depende de los datos proporcionados. Estos servicios son regularmente prestaciones que cubren un tipo de necesidad del usuario.

ServicioInterno: tipo de servicio que se ofrece al personal o estudiantes con respecto a la institución.

ServicioExterno: servicios ofrecidos por la institución a otras organizaciones.


Página 47

4.2.2.4. Atributos de las clases de la ontología

Conectividad: tipo de enlace que se puede establecer a partir de la página que

pertenece a ésta clase. Las variantes de este valor son las siguientes:

o Enlace: la página puede contener un conjunto de enlaces hacia otros elementos

del sitio Web.

Uniforme: conjunto de enlaces que se refieren a una misma temática.

Mixto: diversas agrupaciones de enlaces de distinta temática o tipo.

o Simple: la página es considerada una hoja del sitio Web, es decir, que no

contiene enlaces que estructuralmente lleven hacia otros elementos.

Existencia: se refiere al periodo de vida estimado para una página que pertenece a

ésta clase y sus valores son los siguientes:

o Temporal: una página con un periodo de vida determinado.

o Permanente: aquel elemento que permanece en el tiempo, aun cuando se

realicen cambios sobre él.

Tipo de entidad: tomando en cuenta que existen páginas con niveles compositivos de

tipo concreto; que representan elementos sólidos, compactos o materiales, precisos,

determinados y sin vaguedad; o elementos abstractos que significan alguna cualidad

con exclusión del sujeto. Sus valores son los siguientes:

o Espacio-material: con un nivel compositivo concreto.

o Simbólica: con un nivel compositivo abstracto.

4.2.2.5. Definición de clases de la taxonomía Las clases listadas a continuación son las hojas de la taxonomía de clases. Entre estas clases existe un conjunto de relaciones que son aplicables a sus ejemplares y que se formalizan en la sección posterior.

Tabla 4.3. Definición de la clase Descripción abstracta

Clase: Descripción abstracta

Superclase: Descripción. Definición: Elementos de presentación de la institución. Pueden contender detalles

históricos, definición del perfil de la institución, objetivos, etc. Acción de representar a alguien o algo por medio del lenguaje, refiriendo o explicando sus distintas partes, cualidades o circunstancias.

Instancias: Presentación, misión, visión, objetivo, historia, ubicación, acerca de, servicios. Atributo: Tipo de entidad: simbólica.

Conectividad: simple/enlace. Existencia: permanente.


Página 48

Tabla 4.4. Definición de la clase Descripción física

Clase: Descripción física

Superclase: Descripción. Definición: Elemento que muestra la disposición de los recursos de la institución. Instancias: Directorio, infraestructura, organigrama institucional. Atributo: Tipo de entidad: espacio-material.

Conectividad: simple/enlace. Existencia: permanente.

Tabla 4.5. Definición de la clase Estudiante

Clase: Estudiante

Superclase: Personal. Definición: Contiene información sobre la persona que cursa estudios en una institución

educativa. Instancias: Estudiante de posgrado, estudiante de licenciatura. Atributo: Tipo de entidad: espacio-material.

Conectividad: simple. Existencia: temporal.

Tabla 4.6. Definición de la clase Organización funcionamiento

Clase: Organización funcionamiento

Superclase: Estructura. Definición: Elemento que muestra la administración o coordinación de un proceso de

manera formal. Instancias: Reglamento, plan de estudios. Atributo: Tipo de entidad: simbólica.

Conectividad: simple. Existencia: permanente.

Tabla 4.7. Definición de la clase Producto

Clase: Producto

Superclase: Documento. Definición: Representa un objeto que percibe un consumidor o un conjunto de beneficios

o satisfacciones. En los centros de investigación, los productos son el resultado de la investigación científica.

Instancias: Tesis, publicación. Atributo: Tipo de entidad: espacio-material.


Tabla 4.8. Definición de la clase Servicio externo

Clase: Servicio externo

Superclase: Servicio. Definición: Servicios ofrecidos por la institución a otras organizaciones. Instancias: Capacitación, consultoría, bolsa de trabajo.


Página 49

Atributo: Tipo de entidad: simbólica. Conectividad: simple. Existencia: permanente.

Tabla 4.9. Definición de la clase Servicio interno

Clase: Servicio interno

Superclase: Servicio. Definición: Tipo de servicio que se ofrece al personal o estudiantes con respecto a la

institución. Instancias: Búsqueda, consulta bibliográfica, correo electrónico, kardex, centro de

idiomas. Atributo: Tipo de entidad: simbólica.


Tabla 4.10. Definición de la clase Suceso

Clase: Suceso

Superclase: Información. Definición: Acontecimiento relevante o actividad que posee carácter de importancia en

una temporada específica. Instancias: Noticia, evento, curso. Atributo: Tipo de entidad: simbólica.


Tabla 4.11. Definición de la clase Trabajador

Clase: Trabajador

Superclase: Personal. Definición: Contiene información sobre la persona que labora en un organismo,

dependencia o institución. Instancias: Académico, administrativo. Atributo: Tipo de entidad: espacio-material.


Tabla 4.12. Definición de la clase Trámite

Clase: Trámite

Superclase: Información. Definición: Consecución de pasos para desarrollar una tarea de interés para los

estudiantes o el personal de la institución. Los trámites suelen ser actividades obligatorias.

Instancias: Admisión, titulación, beca, servicio social, residencia profesional, actividad extraescolar.

Atributo: Tipo de entidad: simbólica. Conectividad: simple. Existencia: permanente.


Página 50

Tabla 4.13. Definición de la clase Unidad organizacional

Clase: Unidad organizacional

Superclase: Estructura. Definición: Espacio de trabajo o unidad administrativa de la institución. Se identifica por

las funciones que lleva a cabo, el conjunto de responsabilidades que asume o por identificar a una agrupación.

Instancias: Departamento, línea de investigación, posgrado, principal, personas, bienes. Atributo: Tipo de entidad: simbólica.

Conectividad: enlace. Existencia: permanente.

4.2.2.6. Establecimiento de relaciones de la ontología

Figura 4.5. Conjunto de relaciones

La identificación de relaciones para la creación de la ontología no es una tarea sencilla, ya que un sitio Web utiliza entidades abstractas, que resultan difíciles de relacionar. Una página Web es capaz de conceptualizar un objeto que no posee representación física en el mundo real, ejemplo de ello son conceptos como: acerca de o enlace de interés.

Estos conceptos no tienen propiedades físicas que ayuden a identificarlos como partes, todos, generalizaciones o especializaciones de otros elementos o la manera en que interactúan entre ellos mismos. Dichos elementos le permiten a la lingüística o a enfoques como UML definir relaciones.

Es por ello que las relaciones entre los conceptos del dominio de educación, aplicadas en esta investigación, conjuntan propiedades y tipos encontrados en la literatura. Primero se

class System

Léxica

Léxica

paradigmática

Léxica

sintagmática

Meronimia

Meronimia

Canónica-

Canónica

Meronimia

Canónica-

Facultativ a

Meronimia

Facultativ a-

Canónica

Meronimia

Facultativ a-

Facultativ a

Meronimia

Colección-

Miembro

Meronimia Grupo-

Miembro

Meronimia E

Meronimia F

Meronimia G

Meronimia H

Meronimia I Meronimia K Meronimia L

Meronimia M

Meronimia N Meronimia A Meronimia B Meronimia D Meronimia C

Hiperonimia

Topológica

Produce Registra


Página 51

tomó como base las relaciones léxicas (sintagmáticas y paradigmáticas), así como las propuestas por Cruse [CRUSE 1986] aplicando propiedades de la mereología y UML.

Las relaciones resultantes se describen a continuación y se resumen en la figura 4.5.

(A) Meronimia Facultativa-Facultativa: esta meronimia se aplica a todos y partes que

están unidos de manera opcional, pues en muchos casos el concepto que representa a la parte está compartido, es decir que puede aparecer en varias secciones del sitio Web. Para la existencia de la relación es necesario unir como máximo un todo con una única parte del conjunto de posibles partes.

El todo puede tener a la parte de manera opcional.

La parte puede pertenecer al todo de manera opcional.

La parte es un concepto que puede ser compartido, apareciendo en diversas partes del

sitio Web.

De existir una parte dentro del todo, no puede existir otro elemento de la misma clase

como parte del todo.

Al eliminar el todo se elimina siempre la parte.

Al eliminar la parte no se elimina el todo.

No es posible crear un enlace desde la parte hacia el todo de manera dinámica.

El dominio y rango de esta relación están dados por las siguientes clases que se

muestran en la tabla 4.14 (definidas en 4.2.2.5):

Tabla 4.14. Dominio y rango para la relación (A) Meronimia Facultativa-Facultativa

Dominio Rango

Unidad organizacional Organización funcionamiento Unidad organizacional Descripción abstracta Unidad organizacional Descripción física Unidad organizacional Unidad organizacional

(B) Meronimia Facultativa-Facultativa: esta meronimia se aplica a todos y partes que

están unidos de manera opcional, pues en muchos casos el concepto que representa a la parte está compartido, es decir que puede aparecer en varias secciones del sitio Web. Para la existencia de la relación es posible unir un todo con una infinidad de partes de la misma clase.

El todo puede tener a la parte de manera opcional.


La parte 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.



Es posible crear enlace dinámicamente hacia nuevas partes.


Página 52



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.



Tabla 4.16. Dominio y rango para la relación (C) Meronimia Grupo-Miembro:

Dominio Rango

Unidad organizacional Estudiante Unidad organizacional Trabajador

(D) Meronimia Colección-Miembro: esta meronimia es aplicable a documentos que representan elementos inanimados que conforman colecciones de objetos de cierto tipo.

El todo es una colección.

La parte es un objeto que pasa a formar parte de la colección.

Un objeto pertenece de manera obligatoria a una colección, es decir, la colección debe

tener como parte a un elemento de la clase miembro.

Una colección puede conformarse de n número de miembros de la misma clase,

teniendo por lo menos uno.

Una colección no puede eliminarse mientras existan miembros dentro de ella.

Al eliminar un miembro, la colección permanece.

Es posible crear enlaces a nuevos miembros de la colección.




Página 53

Tabla 4.17. Dominio y rango para la relación (D) Meronimia Colección-Miembro

Dominio Rango

Unidad organizacional Producto

(E) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que

están unidos de manera obligatoria, pues la existencia de la relación implica que la parte debe encontrarse en el todo y que el todo necesita de la parte.

El todo tiene a la parte de manera obligatoria.

La parte puede pertenecer al todo de manera obligatoria.

La parte existe si existe el todo, es decir, hay una dependencia existencial entre los dos

elementos.

Es necesario que existan la parte en el todo y no es posible que exista otro elemento de

la misma clase como parte del todo.


Al eliminar la parte se elimina siempre el todo.

No es posible crear enlaces dinámicamente hacia nuevas partes.



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.



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 n número de

elementos de esta clase como partes del todo.

Es posible crear enlaces dinámicamente hacia nuevas partes.




Página 54

Tabla 4.19. Dominio y rango para la relación (F) Meronimia Canónica-Canónica

Dominio Rango

Unidad organizacional Unidad organizacional

(G) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que


El todo contiene a la parte 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


No es posible eliminar un todo sin antes eliminar las partes que lo conforman.





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.



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.






Página 55

Tabla 4.21. Dominio y rango para la relación (H) Meronimia Canónica-Canónica

Dominio Rango

Unidad organizacional Descripción abstracta

(I) Meronimia Canónica-Canónica: esta meronimia se aplica a todos y partes que



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







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.



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.







Página 56

Tabla 4.23. Dominio y rango para la relación (J) Meronimia Canónica-Canónica

Dominio Rango

Unidad organizacional Descripción abstracta

(K) Meronimia Canónica-Facultativa: esta meronimia se aplica a todos obligatorios

con partes opcionales, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.



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







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.





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.







Página 57

Tabla 4.25. Dominio y rango para la relación (L) Meronimia Canónica-Facultativa

Dominio Rango

Descripción abstracta Descripción física

(M) Meronimia Canónica-Facultativa: esta meronimia se aplica a todos obligatorios

con partes opcionales, pues la existencia de la relación implica que la parte podría encontrarse en el todo y que el todo necesita de la parte.





Debe existir un elemento de la clase como parte del todo y puede existir n número de







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.







Página 58

Tabla 4.27. Dominio y rango para la relación (N) Meronimia Facultativa -Canónica

Dominio Rango

Unidad organizacional Trámite

Topológica: esta relación aplica entre sustantivos que permanecen unidos por un

tiempo determinado.

El elemento del rango puede enlazarse dinámicamente hacia el dominio.

Al desaparecer el elemento del rango no se elimina el elemento del dominio.

Pueden existir diferentes elementos de la clase del rango en el elemento de la clase del

dominio.



Tabla 4.28. Dominio y rango para la relación Topológica

Dominio Rango

UnidadOrganizacional Suceso

Produce: indica que existen dos entidades donde una lleva a cabo la acción de producir y la otra es el resultado de la acción.

El elemento del dominio puede enlazarse dinámicamente hacia el elemento del rango

y viceversa.

Al desaparecer el elemento del dominio no es necesario que el elemento del rango

desaparezca.

Al desaparecer el elemento del rango no es necesario que el elemento del dominio

desaparezca.

Un elemento del dominio puede relacionarse con varios elementos del rango y

viceversa.



Tabla 4.29. Dominio y rango para la relación Produce

Dominio Rango

Trabajador Producto

Registra: indica que existen dos entidades donde una lleva a cabo la acción de registrar y la otra es el elemento que se registra.


Página 59

El elemento del dominio puede enlazarse dinámicamente hacia el elemento del rango

y viceversa.

Al desaparecer el elemento del dominio no es necesario que el elemento del rango

desaparezca.

Al desaparecer el elemento del rango no es necesario que el elemento del dominio

desaparezca.

Si desaparecen todos los elementos del rango, no es lógico que exista en elemento del

dominio.

Un elemento del dominio puede relacionarse con diferentes elementos del rango.

Un elemento del rango puede relacionarse con diferentes elementos del dominio.



Tabla 4.30. Dominio y rango para la relación Registra

Dominio Rango

DescripciónFísica Trabajador


Página 60

Tabla 4.31. Conjunto de propiedades para relaciones meronímicas

Tipo de relación Multiplicidad Propagación

de borrado Comportamiento temporal

Dominio y rango Propiedad secundaria

(A) Meronimia facultativa-facultativa

0..1, 0..1 Cascada-Enlace

Dinámico-Estático UnidadOrganizacional-OrganizaciónFuncionamiento UnidadOrganizacional-DescripciónAbstracta UnidadOrganizacional-DescripciónFísica UnidadOrganizacional-UnidadOrganizacional

Concepto compartido

(B) Meronimia facultativa-facultativa

0..1, 0..* Cascada-Enlace

Dinámico-Dinámico

DescripciónAbstracta-OrganizaciónFuncionamiento

Concepto compartido

(C) Meronimia grupo-miembro

1,* Restringido-Enlace

Dinámico-Estático UnidadOrganizacional-Estudiante UnidadOrganizacional-Trabajador

Parte exclusiva

(D)Meronimia colección-miembro

1, 1..* Restringido-Enlace

Dinámico-Estático UnidadOrganizacional-Producto Parte obligatoria

(E) Meronimia canónica-canónica

1,1 Cascada-Cascada

Estático-Estático UnidadOrganizacional-OrganizaciónFuncionamieto

Dependencia existencial

(F) Meronimia canónica-canónica

1, 1..* Cascada-Enlace

Dinámico-Estático UnidadOrganizacional-UnidadOrganizacional DescripciónAbstracta-ServicioInterno DescripciónAbstracta-ServicioExterno

Parte obligatoria

(G) Meronimia canónica-canónica

1, 1..* Restringido-Enlace

Dinámico-Dinámico

UnidadOrganizacional-DescripciónFísica

Todo obligatorio

(H) Meronimia canónica-canónica

1,1 Cascada-Enlace

Estático-Estático UnidadOrganizacional-DescripciónAbstracta

Parte obligatoria

(I) Meronimia canónica-canónica


Dinámico-Estático UnidadOrganizacional-UnidadOrganizacional

Parte exclusiva

(J) Meronimia canónica-canónica

1,1 Cascada-Enlace

Estático-Estático UnidadOrganizacional-DescripciónAbstracta

Parte obligatoria


Página 61

(K) Meronimia canónica-facultativa


Estático-Estático DescripciónAbstracta-DescripciónAbstracta

Parte obligatoria

(L) Meronimia canónica-facultativa

0..1, 1 Cascada-Enlace

Estático-Estático DescripciónAbstracta-DescripciónFísica

Parte obligatoria

(M)Meronimia canónica-facultativa


Dinámico-Estático DescripciónFísica- UnidadOrganizacional

Parte obligatoria

(N) Meronimia facultativa-canónica


Dinámico-Estático UnidadOrganizacional-Trámite Parte exclusiva

Topológica 1, 0..* Cascada-Enlace

Dinámico-Dinámico

UnidadOrganizacional-Suceso Ninguna

Registra 1, 0..* Enlace-Enlace

Dinámico-Estático Trabajador-DescripciónFísica Ninguna

Produce 1..*, 1..* Enlace-Enlace

Dinámico-Estático Estudiante-Producto Trabajador-Producto

Ninguna


Página 62

4.3. Editor de estructuras de sitios Web

Para construir el editor se realizó un análisis de requerimientos previo, que refleja los problemas y necesidades del usuario.

4.3.1. Análisis de requerimientos del usuario

Se identificaron dos posibles situaciones que pueden darse entre el usuario y la herramienta:

Crear un sitio Web nuevo: implica la construcción total de la estructura del sitio.

Editar un sitio Web construido previamente con la herramienta propuesta: se refiere a un sitio Web cuya estructura fue construida utilizando el editor propuesto.

4.3.2. Arquitectura general de la herramienta y descripción de las funciones

En esta sección se muestra la arquitectura general del software y se describen los módulos que se consideran necesarios para el desarrollo de la herramienta. Las funciones obtenidas son resultado del análisis de requerimientos.

Figura 4.6. Arquitectura general del editor EDWEB

class Domain Objects

Editor manual de

grafos Verificador

Generador de

estructura

Panel de

v isualización de

grafos

Archiv os

Usuario

Buscar XML

Retorna XML

Entrada

XML a verificar

XML verificado

XML para creación de estructuraXML a interpretar Grafo del XML

Archivos para almacenamiento

Salida


Página 63

Crear grafo del sitio Web: esta tarea está soportada por la aplicación LinkBrowser de

Touchgraph, sin embargo se realizaron modificaciones al código para crear grafos con

nodos etiquetados a partir de un árbol de conceptos que deberá ser formado

automáticamente a partir de un archivo OWL de la ontología. De la misma manera se

realizaron las modificaciones pertinentes para obtener aristas etiquetadas con las

relaciones establecidas en la ontología.

Crear archivo XML a partir de un grafo: con LinkBrowser es posible crear archivos

descriptivos, por lo que se ha hecho una modificación para almacenar los nombres en

las aristas del grafo al archivo XML de la estructura.

Generar grafo a partir de un archivo XML: se realizaron pequeñas modificaciones

para crear el grafo con aristas etiquetadas.

Generar estructura del sitio Web: la herramienta LinkBrowser no es capaz de crear

páginas en blanco del sitio Web, por lo que esta funcionalidad fue añadida en el editor

de sitios.

Crear reporte de errores: se agregó un módulo de análisis del grafo dibujado,

incluyendo los errores existentes al momento de crearlo, como la falta de relaciones

entre los conceptos.

Validar estructura del sitio Web: el editor debe proporcionar una manera de

identificar que los elementos de un grafo, que conforman el archivo XML del sitio

Web, están debidamente etiquetados.

4.3.3. Usuarios de la herramienta

1) Administrador del sitio Web

El administrador del sitio Web es conocido también como Webmaster. Se encarga de administrar el sitio Web, tal como su nombre lo indica. Entre sus tareas se encuentran la de crear y manejar la información y la organización de un sitio Web, de acuerdo al tamaño del mismo.

En sitios grandes se encarga de la supervisión del diseño del sitio, mientras que en

sitios pequeños lleva a cabo la creación y el mantenimiento.

2) Arquitecto de la información

Integra los componentes del sitio Web y la manera en que el usuario navegará de una página a otra.

Una de sus tareas es la de diseñar un mapa de sitio que muestre las secciones principales del sitio. Posteriormente, el IA17, se dedica a los detalles a nivel página y crea una serie de

17 Arquitecto de la Información, por sus siglas en inglés.


Página 64

maquetas de la arquitectura de las páginas y esbozos de diseño18 que muestran el contenido y los elementos de navegación que componen cada página del sitio.

4.3.4. Limitaciones de la herramienta

El editor no tiene limitantes en cuanto al lenguaje de desarrollo o la plataforma, sin embargo, se debe establecer un ambiente adecuado de acuerdo al tipo de herramienta a desarrollar.

El producto se cataloga como un software de aplicación monopuesto, porque ayuda al

usuario con un solo rol de interacción a desarrollar tareas específicas.

La aplicación se ejecutará sobre un equipo local, sin el uso de servidores o conexiones

a red.

En cuanto a la aplicación del análisis, se utilizan relaciones estáticas. No es posible

definir nuevos tipos de relaciones, para llevar un control en las restricciones y la

manera en que se enlazan los nodos de los grafos.

Las validaciones son exclusivas a las relaciones definidas en el grafo, ya que no se

contempla contenido.

4.4. Diseño

Esta sección muestra los casos de uso de la herramienta y sus especificaciones.

4.4.1. Diagramas de casos de uso

Se muestran a continuación los diagramas de caso de uso del editor contemplados para este trabajo.

18 Las maquetas son borradores que muestran contenido y vínculos entre las páginas. Los esbozos se basan en las maquetas y son un primer intento por diseñar la interfaz de las páginas de nivel superior del sitio.


Página 65

Figura 4.7. Casos de uso

Se observa como primer caso de uso la creación manual de un grafo que corresponde al caso en el que no existe un sitio previo y debe generarse desde el principio. Existe la posibilidad de que la creación del grafo incluya la visualización de una estructura previamente construida que se toma como base para el diseño.

La creación de un reporte de errores de una estructura implica que se creará primero

un grafo. Lo mismo ocurre en el caso de la generación de la estructura del sitio Web, que requiere a su vez de la creación de un reporte de errores.

Tabla 4.32. Propiedades de CU-1 Crear grafo del sitio Web

ID: CU-1 Crear grafo del sitio Web

Actores: Constructor del sitio Web. Descripción: Permite al usuario crear un nuevo grafo en el panel de edición. Precondiciones: 1. Debe cargarse la ontología requerida en la aplicación Poscondiciones: 1. Se obtiene un grafo con nodos y aristas etiquetadas Escenario de éxito 1: 1. Se abre la aplicación

2. Se carga la ontología requerida


Página 66

3. El usuario toma un concepto de la lista de clases generada 4. El usuario selecciona una relación 5. Se genera una tripleta válida 6. Se repiten las acciones 3, 4 y 5 hasta que el usuario completa el grafo

Suposición: Supone que la ontología para esta aplicación ha sido creada.

Tabla 4.33. Propiedades de CU-2 Crear archivo XML a partir de un grafo

ID: CU-2 Crear archivo XML a partir de un grafo

Actores: Constructor del sitio Web. Descripción: Permite al usuario generar el archivo descriptivo de la estructura de un

sitio Web a partir de un grafo. Precondiciones: 1. Debe existir un grafo creado previamente

2. Todos los nodos y aristas del grafo deben estar etiquetados Poscondiciones: 1. Se almacena un archivo XML con una sección descriptiva para nodos y

otra para aristas Escenario de éxito 1: 1. Se crea un grafo previamente

2. Se selecciona del menú la opción de guardar un archivo como 3. El archivo es nombrado y almacenado

Escenario de éxito 2: 1. Se abre un archivo XML previamente creado 2. Se realizan modificaciones al grafo visualizado 3. Se selecciona del menú la opción de guardar un archivo como 4. El archivo es nombrado y almacenado

Suposición: Supone que cada nodo y arista han sido nombrados y que el grafo es coherente.

Tabla 4.34. Propiedades de CU-3 Generar grafo a partir de un archivo XML

ID: CU-3 Generar grafo a partir de un archivo XML

Actores: Constructor del sitio Web. Descripción: Permite al usuario visualizar un grafo a partir de un archivo XML que se

ha creado con anterioridad. Precondiciones: 1. Debe existir un archivo XML guardado Poscondiciones: 2. El grafo creado en el panel debe mostrar los nodos y aristas que no están

etiquetados. Escenario de éxito 1: 1. Se abre un archivo XML existente

2. Se muestra en el panel el grafo descrito por el archivo XML 3. Los nodos y aristas indefinidos se muestran en un color distinto al resto del grafo.

Suposición: El archivo XML utilizado mantiene la estructura del DTD.

Tabla 4.35. Propiedades de CU-4 Generar estructura del sitio Web

ID: CU-4 Generar estructura del sitio Web

Actores: Constructor del sitio Web. Descripción: Permite al usuario crear un conjunto de páginas basadas en un grafo

diseñado en la herramienta editor. Precondiciones: 1. Debe crearse y guardarse un archivo XML previamente

2. El archivo XML debe ser verificado para validar sus consistencia Poscondiciones: 1. Las páginas creadas deben contener los enlaces correspondientes hacia


Página 67

otras páginas Escenario de éxito 1: 1. Se crea un archivo XML y se almacena

2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y se crea una carpeta con un conjunto de paginas enlazadas

Escenario de éxito 2: 1. Se crea un archivo XML y se almacena 2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y la carpeta ya existe 4. Se solicita la reescritura de la carpeta o el almacenamiento del archivo XML con otro nombre 5. Se almacena el archivo y se selecciona nuevamente la opción de generar estructura 6. La carpeta se crea exitosamente

Escenario de fracaso 1:

1. Se crea un archivo XML y se almacena 2. Se verifica la consistencia del grafo 3. Se selecciona del menú la opción de generar estructura y la carpeta ya existe 4. Se solicita la reescritura de la carpeta o el almacenamiento del archivo XML con otro nombre 5. La carpeta no se sobreescribe y por tanto no se almacena

Suposición: La carpeta no existe o si existe se desea realizar cambios en ella y es posible sobreescribirla.

Tabla 4.36. Propiedades de CU-5 Crear reporte de errores

ID: CU-5 Crear reporte de errores

Actores: Constructor del sitio Web. Descripción: Proporcionar al usuario un elemento que le permita listar la serie de

errores encontrados en el grafo. Precondiciones: 1. Debe existir un grafo creado previamente Poscondiciones: 1. El reporte generado indica los nodos origen y destino de la arista

indefinida Escenario de éxito 1: 1. Se abre un archivo XML existente

2. Se selecciona del menú la opción de verificar grafo 3. En el panel del reporte se listan los nodos origen y destino de los enlaces con etiqueta indefinida

Escenario de éxito 2: 1. Se abre un archivo XML existente 2. Se selecciona del menú la opción de verificar grafo 3. En el panel del reporte aparece un mensaje que indica que el grafo está correctamente enlazado

Suposición: El archivo XML existe.

Tabla 4.37. Propiedades de CU-6 Validar estructura del sitio Web

ID: CU-6 Validar estructura del sitio Web

Actores: Constructor del sitio Web. Descripción: La validación ayuda al usuario a detectar posibles inconsistencias en el

grafo creado. Precondiciones: 1. El grafo está siendo modificado

2. El grafo ha sido previamente guardado Poscondiciones: 1. Se indica en el grafo, con un cambio de color, las aristas o nodos

etiquetados incorrectamente


Página 68

2. Se indica la falta de etiquetas en los nodos Escenario de éxito 1: 1. Se abre un archivo XML existente

2. El grafo se visualiza en el panel de edición de grafos 3. Las aristas y nodos no etiquetados o etiquetados como indefinidos se observan en un tono de color distinto a los demás elementos del grafo

Escenario de éxito 2: 1. Se crea o se abre un archivo XML 2. Se desea realizar una modificación a una arista 3.La arista se etiqueta como indefinida 4. La arista indefinida se observa en un color diferente al resto del grafo

Suposición: El usuario, premeditadamente, nombra una arista como indefinida pues no conoce, por el momento, el tipo de relación existente entre dos elementos. El usuario elimina el nombre de un nodo en el archivo XML.

Capítulo 5. Implementación

El presente capítulo muestra la implementación de la ontología diseñada y describe la herramienta desarrollada para el trabajo de investigación. Dentro de este capítulo se observan los flujos de actividades de las tareas desarrolladas con el editor de sitios Web, así como las clases que se involucran en ellas.


Página 70

5.1. Creación de la ontología con la herramienta Protégé

Para la implementación se tomó en cuenta la creación de la ontología para sitios Web del dominio de educación por medio de la herramienta Protégé. Protégé permite describir una jerarquía de clases de la ontología, sus atributos (slots) y las instancias de la base de conocimiento. El primer paso consiste en la creación de la jerarquía de clases, mostrada en la figura siguiente. Las clases se listan iniciando con la clase Documento y a partir de ella se crean elementos más particulares hasta llegar a las hojas de la jerarquía.

Figura 5.1. Jerarquía de clases

Para enlazar a dos individuos se crean relaciones binarias llamadas propiedades. Estas

propiedades son el equivalente a las relaciones encontradas en la etapa de desarrollo de la metodología.


Página 71

Figura 5.2. Conjunto de propiedades

Existen dos tipos de propiedades principales: propiedades de objetos y propiedades

de tipo de dato. Las propiedades mostradas en la figura 5.1 son propiedades de objeto, pues enlazan a un individuo con otro, a diferencia de las de dato que enlazan un individuo con un símbolo o dato.

5.2. Desarrollo de la aplicación

5.2.1. Características generales de implementación

Para llevar a cabo la implementación se utilizaron las siguientes herramientas:

Para la el desarrollo de la aplicación se utilizará Java J2SE Development Kit en su

versión 1.6.0, soportado sobre Microsoft Windows. Esta versión proporciona un

compilador y un conjunto de herramientas para crear programas independientes y

java applets.


Página 72

Para la creación de la ontología del dominio de educación se utilizó el editor de

ontologías Protégé en su versión 3.4 Beta.

La explotación de la ontología para la herramienta fue llevada a cabo por medio de la

API Jena en su versión 2.5.5.

5.2.2. Implementación de módulos

Los detalles mostrados a continuación se refieren a cada módulo implementado de la herramienta de software EDWEB.

Los módulos implementados tienen su equivalente con un caso de uso de la fase de análisis.

5.2.2.1. Carga de la ontología La figura 5.3 muestra las clases necesarias para obtener acceso a la ontología del dominio de educación creada con la herramienta Protégé. Para ello se importa la API Jena, que permite la explotación de datos de la ontología en formato OWL. Las librerías Individual, OntClass y Resource, ayudan a manejo de nodos, descripciones de clases y manejo de recursos RDF.

La clase JenaParser se utiliza para mostrar las clases, instancias y las clases inferidas

con el modelo de inferencia. Las clases e instancias obtenidas de la ontología en OWL se listan en una instancia de

la clase JTree, aunque se listan únicamente las hojas de la ontología pues son éstas las utilizadas en la creación de grafos.


Página 73

Figura 5.3. Clases para explotación de la ontología

5.2.2.2. Creación de grafos con la herramienta Este módulo es equivalente al CU-1 Crear grafo del sitio Web. Para la creación de un nuevo grafo con el editor de sitios Web se usan las clases Node y LBNode con el argumento que corresponde al nombre del nodo principal por defecto.

Esta acción creará un nuevo panel de trabajo con un nodo inicial llamado “UnidadOrganizacional:Principal”.

Un grafo se conforma de un número de nodos, tomados de la lista de clases de la

ontología, y aristas proporcionadas por el usuario. Los nodos poseen propiedades por defecto como nombre, tipo de clase a la que pertenece e incluso un campo descriptivo.

Las aristas se crean por medio de las clases Edge y LBEdge. Requieren como

parámetros de entrada, un nodo origen, un nodo destino y una longitud de arista. Este último valor es tomado de los datos por defecto.

Al completar una tripleta existe un proceso de validación de la misma, asegurándose

de que dichos nodos pueden enlazarse por medio de la relación seleccionada. La clase Validator contiene el método validate, encargado de la verificación de la tripleta generada. Para realizar la validación se envían los datos de la tripleta (objetos LBNode y LBEdge) a la clase Validator desde el método mouseReleased de la clase LBDragAddNodeUI.

class client

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane

~ completeEltSet: GraphEltSet = null

- documentBase: URL

- enclosingApplet: JApplet = null

- enclosingFrame: JFrame = null

~ externalFrame: String

~ graphsVisited: Stack = new Stack() {readOnly}

+ hvScroll: HVScroll

~ initialNodeName: String

# lbEdgeDialog: LBEdgeDialog

# lbNodeDialog: LBNodeDialog

+ lbPopup: JPopupMenu

+ listReport: JList

+ localityScroll: LocalityScroll

~ modeSelectPanel: JPanel

~ openFile: JButton = new JButton()

- parser: JenaParser = null

~ proxyServlet: String

+ rotateScroll: RotateScroll

~ scrollBarHash: Hashtable = new Hashtable() {readOnly}

~ targetFrame: String

~ textOntology: JTextField = new JTextField()

~ tgLensSet: TGLensSet

~ tgPanel: TGPanel

~ tgUIManager: TGUIManager

~ xmlFileName: String

~ xmlio: XMLio

+ zoomScroll: ZoomScroll

+ addElement(Vector) : void

- addUIs() : void

- buildLens() : void

- buildPanel() : void

- createParameterHash() : Hashtable

+ getDocumentBase() : URL

+ getTGPanel() : TGPanel

- jbInit() : void

- lblMenuBarPrincipal() : JMenuBar

+ main(String[]) : void

~ processNodeUrl(LBNode) : void

- restoreSavedParameters(Hashtable) : void

~ salir_ActionPerformed(ActionEvent) : void

~ scrollSelectPanel(String[]) : JPanel

+ setLocale(String, int) : void

+ TGLinkBrowser()

+ TGLinkBrowser(JApplet)

~ TGLinkBrowser(JFrame)

+ titles(String, int, int, int, int) : JLabel

JenaParser

- fi le: File = null

- model: OntModel = null

+ getIndividuals() : List<Individual>

+ getInfModel() : InfModel

+ getOntClass() : List<OntClass>

+ JenaParser(File)

-parser


Página 74

Finalmente, al crear la tripleta se despliega una ventana de edición del nodo donde el usuario puede modificar las características del nodo destino. Para ello, la clase LBNodeDialog cuenta con el método saveChangesAndHideDialog.

Figura 5.4. Diagrama de actividades para la creación de grafos

La figura 5.4 muestra el diagrama de las actividades llevadas a cabo para crear un

grafo de sitio nuevo. Las clases que intervienen en esta tarea pueden observarse en la figura 5.5.


Página 75

class client

Edge

# col: Color

+ DEFAULT_COLOR: Color = Color.decode("#...

+ DEFAULT_LENGTH: int = 350

+ from: Node

# length: int

+ MOUSE_OVER_COLOR: Color

+ to: Node

# visible: boolean

+ containsPoint(double, double) : boolean

+ distFromPoint(double, double) : double

+ Edge(Node, Node, int)

+ Edge(Node, Node)

+ getColor() : Color

+ getFrom() : Node

+ getLength() : int

+ getOtherEndpt(Node) : Node

+ getTo() : Node

+ intersects(Dimension) : boolean

+ isVisible() : boolean

+ paint(Graphics, TGPanel) : void

+ paintArrow(Graphics, int, int, int, int, Color) : void

+ reverse() : void

+ setColor(Color) : void

+ setEdgeDefaultColor(Color) : void

+ setEdgeDefaultLength(int) : void

+ setEdgeMouseOverColor(Color) : void

+ setLength(int) : void

+ setVisible(boolean) : void

GraphEltSet

# edges: Vector

+ nodeCount: int

# nodeIDRegistry: Hashtable = null

# nodes: Vector

+ addEdge(Edge) : void

+ addEdge(Node, Node, int) : Edge

+ addNode(Node) : void

+ calculateDistances(Node, int) : Hashtable

+ clearAll() : void

+ contains(Node) : boolean

+ contains(Edge) : boolean

+ deleteEdge(Edge) : boolean

+ deleteEdge(Node, Node) : boolean

+ deleteEdges(Vector) : void

+ deleteNode(Node) : boolean

+ deleteNodes(Vector) : void

# edgeAt(int) : Edge

+ edgeNum() : int

+ findEdge(Node, Node) : Edge

+ findNode(String) : Node

+ findNodesByLabel(String) : Collection

+ forAllEdges(TGForEachEdge) : void

+ forAllNodePairs(TGForEachNodePair) : void

+ forAllNodes(TGForEachNode) : void

+ getFirstNode() : Node

+ getRandomNode() : Node

+ GraphEltSet()

# nodeAt(int) : Node

+ nodeNum() : int

TGAbstractDragUI

LBDragAddNodeUI

~ cboParRel: JComboBox

~ dragAddNode: LBNode

~ mousePos: Point

~ newNode: String = "UnidadOrganiza...

~ result: Boolean

~ tgLinkBrowser: TGLinkBrowser

+ LBDragAddNodeUI(TGLinkBrowser)

+ mouseDragged(MouseEvent) : void

+ mousePressed(MouseEvent) : void

+ mouseReleased(MouseEvent) : void

+ paintAfterEdges(Graphics) : void

+ paintFirst(Graphics) : void

+ paintLast(Graphics) : void

+ preActivate() : void

+ preDeactivate() : void

+ returnData() : String

LBEdge

+ BIDIRECTIONAL_EDGE: int = 0 {readOnly}

+ DEFAULT_TYPE: int = 1

+ edgeType: int

+ HIERARCHICAL_EDGE: int = 1 {readOnly}

- label: String

+ LABEL_BACK_COLOR: Color = new Color(255, ...

+ LABEL_FONT: Font = new Font("Couri...

+ LABEL_TEXT_COLOR: Color

+ getLabel() : String

+ getType() : int

+ LBEdge(LBNode, LBNode)

+ LBEdge(LBNode, LBNode, int)

+ paint(Graphics, int, int, int, int, Color, int) : void


+ 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


+ separatorString(String) : String

+ setHint(String) : void

+ setHintHeight(int) : void

+ setHintIsHTML(boolean) : void

+ setHintWidth(int) : void

+ setNodeHintBackColor(Color) : void

+ setNodeHintFont(Font) : void

+ setNodeHintTextColor(Color) : void

+ setURL(String) : void

+ setURLIsLocal(boolean) : void

+ setURLIsXML(boolean) : void

JInternalFrame

LBNodeDialog

- cbHintIsHTML: JCheckBox

- cbLocal: JCheckBox

- cboFontSize: JComboBox

- cboNodeType: JComboBox

- cbXML: JCheckBox

- cmdCancel: JButton

- cmdOK: JButton

- lastBackColorButton: JButton

- lastTextColorButton: JButton

- lblBackColor: JLabel

- lblTextColor: JLabel

~ lbNode: LBNode

- taHint: JTextArea

- tfBackColor: JTextField

- tfHintHeight: JTextField

- tfHintWidth: JTextField

- tfLabel: JTextField

- tfTextColor: JTextField

- tfURL: JTextField

~ tgPanel: TGPanel

- encodeColor(Color) : String

- initColorSelectors() : void

- initComponents() : void

+ LBNodeDialog(TGPanel)


+ saveChangesAndHideDialog() : void

- setBackColor(Color) : void

+ setLBNode(LBNode) : void

- setTextColor(Color) : void

+ showDialog() : void

Node

+ AUTO_ID_STRING: String = "AutoID " {readOnly}

+ BACK_DEFAULT_COLOR: Color = new Color(208, ...

+ BACK_FIXED_COLOR: Color

+ BACK_HILIGHT_COLOR: Color = Color.decode("#...

+ BACK_SELECT_COLOR: Color = new Color(255, ...

# backColor: Color

+ BORDER_DRAG_COLOR: Color

+ BORDER_INACTIVE_COLOR: Color

+ BORDER_MOUSE_OVER_COLOR: Color = new Color(160, ...


+ 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



+ containsPoint(Point) : boolean

+ edgeAt(int) : Edge

+ edgeNum() : int

+ getBackColor() : Color

+ getFixed() : boolean

+ getFont() : Font

+ getHeight() : int

+ getID() : String


+ getLocation() : Point

+ getName() : String




+ getTextColor() : Color

+ getType() : int

+ getWidth() : int

- initialize(String) : void



+ localEdgeNum() : int

+ Node()

+ Node(String)

+ Node(String, String)

+ Node(String, int, Color, String)


+ 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


+ 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



Runnable

TGLayout

- damper: double

- damping: boolean

~ dragNode: Node

- lastMaxMotion: double

- maxMotion: double

- motionRatio: double

- newRigidity: double

- relaxer: Thread

- rigidity: double

- tgPanel: TGPanel

- avoidLabels() : void

+ damp() : void

- moveNodes() : void

- myWait() : void

- relax() : void

- relaxEdges() : void

+ resetDamper() : void

+ run() : void

~ setDragNode(Node) : void

~ setRigidity(double) : void

+ start() : void

+ startDamper() : void

+ stop() : void

+ stopDamper() : void

+ TGLayout(TGPanel)

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




JPanel

TGPanel

~ adjustOriginLens: AdjustOriginLens

+ BACK_COLOR: Color = Color.white

# basicMML: BasicMouseMotionListener

~ bottomRightDraw: TGPoint2D = null

- completeEltSet: GraphEltSet

~ dragNode: Node

- graphListeners: Vector

- localityUtils: LocalityUtils

# maintainMouseOver: boolean = false

# mouseOverE: Edge

# mouseOverN: Node

# mousePos: Point

- nombreNodo: String

~ offgraphics: Graphics

~ offscreen: Image

~ offscreensize: Dimension

- paintListeners: Vector

# select: Node

~ switchSelectUI: SwitchSelectUI

+ tgLayout: TGLayout


~ topLeftDraw: TGPoint2D = null

- visibleLocality: VisibleLocality



+ addGraphListener(GraphListener) : void

+ addNode() : Node

+ addNode(String) : Node

+ addNode(String, String) : Node


+ addPaintListener(TGPaintListener) : void

+ clearAll() : void

+ clearSelect() : void

+ deleteEdge(Edge) : void

+ deleteEdge(Node, Node) : void


+ deleteNodeById(String) : boolean

+ edgeNum() : int

+ expandNode(Node) : void


# findMouseOver() : void


~ 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


+ multiSelect(TGPoint2D, TGPoint2D) : void

~ myBrihgter(Color) : Color

+ nodeNum() : int

+ paint(Graphics) : void

+ processGraphMove() : void

- redraw() : void

+ removeGraphListener(GraphListener) : void

+ removePaintListener(TGPaintListener) : void

+ repaintAfterMove() : void


+ selectFirstNode() : 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



+ TGPanel()

+ update(Graphics) : void

+ updateDrawPos(Node) : void

+ updateDrawPositions() : void

+ updateGraphSize() : void

+ updateLocalityFromVisibil ity() : void

+ updatePosFromDraw(Node) : void

~tgLinkBrowser

~lbNode

+from

+to

+tgLayout

#select

#mouseOverN

#mouseOverE

~tgPanel

#lbNodeDialog

~tgPanel

~dragNode

-completeEltSet

~completeEltSet

-tgPanel

~dragNode

~dragAddNode

Figura 5.5. Clases para la creación de grafos


Página 76

5.2.2.3. Crear archivo XML a partir de un grafo

El módulo descrito es equivalente al CU-2 Crear archivo XML a partir de un grafo .Al momento de almacenar el archivo XML se llama a la clase XMLio que contiene un conjunto de métodos que permiten la lectura y escritura de nodos y aristas en un archivo que toma como base una DTD.

El archivo de la DTD se divide en dos secciones:

NODESET: contiene los datos del nodo como identificador, etiqueta, localización,

color, fuente y tipo de clase a la que pertenece.

EDGESET: contiene los datos de la arista como la etiqueta, color, nodo origen, nodo

destino y longitud.

Para la creación del XML (figura 5.6) se utiliza un buffer que guarda línea por línea el contenido de la DTD TG_Prepend_DTD.xml y el contenido del grafo, agrupando cada elemento en su sección correspondiente.

La creación del archivo inicia con la clase TGLinkBrowser (figura 5.7), desde la cual el

usuario solicita guardar el archivo XML del grafo creado en el panel. TGLinkBrowser llama al método write de la clase XMLio con el parámetro saveFileStream que contiene la ruta en la que se almacenará el archivo XML.

XMLio crea el archivo XML y copia en los bloques NODESET y EDGESET los datos de

los nodos y aristas.

Figura 5.6. Diagrama de actividades para la creación de un archivo XML


Página 77

class client

Edge

# col: Color



+ from: Node

# length: int


+ to: Node

# visible: boolean




+ Edge(Node, Node)


+ getFrom() : Node

+ getLength() : int


+ getTo() : Node





+ reverse() : void







GraphEltSet

# edges: Vector

+ nodeCount: int


# nodes: Vector





+ clearAll() : void









+ edgeNum() : int









+ GraphEltSet()


+ nodeNum() : int

LBEdge



+ edgeType: int


- label: String





+ getType() : int










LBNode

~ hint: String




~ hintFont: Font

~ hintHeight: int


~ hintWidth: int


~ url: String


~ urlIsXML: boolean

+ getHeight() : int









+ getURL() : String



+ getWidth() : int

+ LBNode()

+ LBNode(String)















Node






# backColor: Color





+ drawx: double

+ drawy: double

# dx: double

# dy: double

- edges: Vector

# fixed: boolean

# font: Font


- id: String


# lbl: String



# nm: String

# repulsion: int


+ TEXT_COLOR: Color


# textColor: Color

# typ: int




# visible: boolean

+ x: double

+ y: double





+ edgeNum() : int



+ getFont() : Font

+ getHeight() : int

+ getID() : String








+ getType() : int

+ getWidth() : int





+ Node()

+ Node(String)



























JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




JPanel

TGPanel






~ dragNode: Node




# mouseOverE: Edge

# mouseOverN: Node

# mousePos: Point



~ offscreen: Image



# select: Node









+ addNode() : Node





+ clearAll() : void






+ edgeNum() : int


























+ nodeNum() : int



- redraw() : void




















+ TGPanel()







XMLio

~ graphEltSet: GraphEltSet

~ parameterHash: Hashtable

- buildGraphEltSet(IXMLElement, Thread) : void


- getBooleanAttr(IXMLElement, String, boolean) : boolean

+ getClassName() : String

+ getLocalDirName() : String

+ getParameterHash() : Hashtable

+ read(String) : void

+ read(URL) : void

+ read(String, Thread) : void

+ read(URL, Thread) : void

+ read(String, InputStream, Thread) : void

+ setParameterHash(Hashtable) : void

+ write(OutputStream) : void

~ XMLio(GraphEltSet)

+from

+to

#select

#mouseOverN

#mouseOverE

~xmlio

~tgPanel

~graphEltSet

-completeEltSet

~completeEltSet

~dragNode

Figura 5.7. Diagrama de clases para la creación de un archivo XML


Página 78

5.2.2.4. Generar grafo a partir de un archivo XML Este módulo es equivalente al CU-3 Generar grafo a partir de un archivo XML. Al generar un grafo a partir de un archivo XML existente, la clase TGLinkBrowser manda al método read de la clase XMLio el parámetro la ruta del archivo almacenada en la variable loadFile. Posteriormente se extrae de la ruta el nombre del archivo.

XMLio verifica el tipo de archivo de entrada y llama al método buildGraphEltSet.

Figura 5.8. Diagrama de clases para la generación de un grafo

a partir de un archivo XML

Las clases que intervienen en esa tarea se muestran en la figura 5.8 y las actividades necesarias para llevarla a cabo se observan en la figura 5.9.

class client

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




XMLio










+ read(URL) : void







~xmlio


Página 79

Figura 5.9. Diagrama de actividades para la generación de un grafo

a partir de un archivo XML

5.2.2.5. Generar estructura del sitio Web

El módulo descrito tiene su equivalente en el CU-4 Generar estructura del sitio Web. Una estructura de sitio Web se compone de un conjunto de páginas en blanco que se encuentran etiquetadas en el archivo XML correspondiente. Cada página contiene los enlaces que la relacionan con otras páginas dentro del sitio Web.

Para la generación de la estructura se ha implementado la clase ParserHTML que contiene métodos para la lectura de archivos XML y la creación de elemento HTML.

La clase ParserHTML contiene al método buildPages que se encarga de la creación del

directorio. Para esto es necesario obtener el nombre del archivo XML con el que se está trabajando. El nombre se almacena en la variable Global.openedFile, que es una variable de tipo Global proveniente de la clase TGLinkBrowser.

Se crea una carpeta con el nombre contenido en dicha variable y en ella se almacenan

las páginas del sitio. Esta tarea implica el recorrido del archivo XML que se hace con elementos de la clase IXMLElement.

Los elementos IXMLElement permiten el acceso a los elementos contenidos en el archivo XML por separado, es decir a las secciones NODESET y EDGESET, de modo que puedan usarse individualmente.

Dentro de buildPages se realizan tres ciclos: el primer ciclo se encarga de dar lectura a

cada nodo almacenado en el archivo XML, dentro de la sección NODESET. Para cada nodo encontrado se crean las cabeceras de la página HTML correspondiente. Un segundo ciclo ayuda a encontrar el nombre de las aristas asociadas al identificador de cada nodo en la


Página 80

sección EDGESET. Por último, el tercer ciclo se encarga de recorrer nuevamente la sección EDGESET para encontrar los nodos destinos con los que cada nodo se relaciona.

Figura 5.10. Diagrama de actividades para la generación de estructuras de sitios Web

De esta manera se insertan los enlaces en cada página (figura 5.10). El diagrama de clases de esta tarea se muestra en la figura 5.11.


Página 81

class client

TGForEachNode

+ forEachNode(Node) : void

+ TGForEachNode()

TGForEachEdge

+ forEachEdge(Edge) : void

+ TGForEachEdge()

Edge

# col: Color



+ from: Node

# length: int


+ to: Node

# visible: boolean




+ Edge(Node, Node)


+ getFrom() : Node

+ getLength() : int


+ getTo() : Node





+ reverse() : void







GraphEltSet

# edges: Vector

+ nodeCount: int


# nodes: Vector





+ clearAll() : void









+ edgeNum() : int









+ GraphEltSet()


+ nodeNum() : int

LBEdge



+ edgeType: int


- label: String





+ getType() : int










JInternalFrame

LBNodeDialog

- cbHintIsHTML: JCheckBox

- cbLocal: JCheckBox

- cboFontSize: JComboBox

- cboNodeType: JComboBox

- cbXML: JCheckBox


- 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




+ LBNodeDialog(TGPanel)



- setBackColor(Color) : void

+ setLBNode(LBNode) : void

- setTextColor(Color) : void


LBNode

~ hint: String




~ hintFont: Font

~ hintHeight: int


~ hintWidth: int


~ url: String


~ urlIsXML: boolean

+ getHeight() : int









+ getURL() : String



+ getWidth() : int

+ LBNode()

+ LBNode(String)















Node






# backColor: Color





+ drawx: double

+ drawy: double

# dx: double

# dy: double

- edges: Vector

# fixed: boolean

# font: Font


- id: String


# lbl: String



# nm: String

# repulsion: int


+ TEXT_COLOR: Color


# textColor: Color

# typ: int




# visible: boolean

+ x: double

+ y: double





+ edgeNum() : int



+ getFont() : Font

+ getHeight() : int

+ getID() : String








+ getType() : int

+ getWidth() : int





+ Node()

+ Node(String)



























ParserHTML



~ v: Vector

- buildPages(IXMLElement) : void

+ ParserHTML()

+ read(String, InputStream) : void

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




JPanel

TGPanel






~ dragNode: Node




# mouseOverE: Edge

# mouseOverN: Node

# mousePos: Point



~ offscreen: Image



# select: Node









+ addNode() : Node





+ clearAll() : void






+ edgeNum() : int


























+ nodeNum() : int



- redraw() : void




















+ TGPanel()







~tgPanel

~lbNode

+from

+to

~dragNode

-completeEltSet

#mouseOverN

~tgPanel

#lbNodeDialog

#mouseOverE

#select

~completeEltSet

~graphEltSet

Figura 5.11. Diagrama de clases para la generación de estructuras de sitios Web


Página 82

5.2.2.6. Generar reporte de errores El caso de uso equivalente a este módulo es CU-5 Crear reporte de errores. Para generar el reporte de errores de la estructura se creó la clase Report (figura 5.12), que contiene al método checkNodes, encargado de revisar el archivo XML, haciendo una enumeración de los elementos del EDGESET. TGLinkBrowser se encarga de enviar a la clase Report el nombre del archivo que desea verificar, el cual se encuentra almacenado en la variable Global.openedFile.

Por medio de ciclos, el mpetodo checkNodes, revisa primero el nodo origen de una

tripleta y después el nodo destino, hasta recorrer el grafo completo. Como resultado se obtiene un vector con las tripletas incorrectas que es enviado de vuelta a TGLinkBrowser.

Figura 5.12. Diagrama de clases para la generación de reporte de errores

La figura 5.13 muestra el diagrama de actividades para la generación del reporte de errores.

class client

Edge

LBEdge



+ edgeType: int


- label: String





+ getType() : int










Report

~ contEdge: int = 0


~ newEdge: LBEdge


~ tgPanel: TGPanel

~ v: Vector

- checkNodes(IXMLElement) : Vector


+ read(String, InputStream) : Vector

+ Report(GraphEltSet, TGPanel)

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




Node

LBNode

~ hint: String




~ hintFont: Font

~ hintHeight: int


~ hintWidth: int


~ url: String


~ urlIsXML: boolean

+ getHeight() : int









+ getURL() : String



+ getWidth() : int

+ LBNode()

+ LBNode(String)















~newEdge


Página 83

Figura 5.13. Diagrama de actividades para la generación de reporte de errores

5.2.2.7. Validar la estructura de sitio Web Este módulo tiene su equivalente en el CU-6 Validar estructura del sitio Web. La validación se realiza de modo que el usuario pueda percibir visualmente que existen inconsistencias en el grafo creado. Las inconsistencias pueden ser de dos tipos:

Nodos creados sin etiqueta: al crear un nodo se omite la asignación de un nombre, por

lo que en el grafo se observa únicamente el nombre de la clase a la que pertenece el

ejemplar.

Aristas creadas o modificadas con etiqueta indefinida: al crear una relación entre

nodos se establece como indefinida o se modifica su valor si no se sabe con exactitud

el tipo de relación existente entre los ejemplares.

Esta validación se lleva a cabo al momento de abrir un archivo XML cuando la clase TGLinkBrowser se encarga de llamar al método read de la clase XMLio. Otro modo de hacerlo es a través de la edición de los elementos del grafo, con la LBEdgeDialog.

La clase LBEdgeDialog en el método saveChangesAndHideDialog permite realizar cambios en el color de las aristas si éstas no están definidas. Esto se debe a que el método asigna los datos proporcionados en la ventana por el usuario a las propiedades de la arista en las clases Edge y LBEdge. Al cambiar el valor de la etiqueta label de la arista al valor de Indefinida, ocurre un cambio en la apariencia de la misma.


Página 84

Figura 5.14. Diagrama de actividades para la validación de estructuras de sitios Web

Otro modo de validar ocurre en la clase LBNodeDialog, cuando, al agregar un nuevo

nodo se omite la inserción de una etiqueta con el nombre del nodo que debe almacenarse junto con las otras propiedades.

Figura 5.15. Diagrama de clases para la validación de estructuras de sitios Web

class client

JInternalFrame

LBEdgeDialog

- cboEdgeLabel: JComboBox

- cboEdgeType: JComboBox


- cmdOK: JButton

- lastEdgeColorButton: JButton

~ lbEdge: LBEdge

- lblEdgeColor: JLabel

- tfEdgeColor: JTextField

- tfEdgeLength: JTextField

~ tgPanel: TGPanel




+ LBEdgeDialog(TGPanel)



- setEdgeColor(Color) : void

+ setLBEdge(LBEdge) : void


TGUserInterface

LBEditUI

~ dragAddNodeUI: LBDragAddNodeUI

~ dragNodeUI: DragNodeUI

~ edgePopup: JPopupMenu

~ hvDragUI: TGAbstractDragUI

~ ml: LBEditMouseListener

~ mml: LBEditMouseMotionListener

~ nodePopup: JPopupMenu

~ popupEdge: LBEdge

~ popupNode: LBNode

~ switchSelectUI: TGAbstractClickUI

~ tgLinkBrowser: TGLinkBrowser

~ tgPanel: TGPanel

+ activate() : void

+ deactivate() : void

+ LBEditUI(TGLinkBrowser)

- setUpEdgePopup() : void

- setUpNodePopup() : void

MouseAdapter

LBEditUI::LBEditMouseListener

~ LBEditMouseListener()

+ mouseClicked(MouseEvent) : void

+ mousePressed(MouseEvent) : void

+ mouseReleased(MouseEvent) : void

MouseMotionAdapter

LBEditUI::LBEditMouseMotionListener

~ LBEditMouseMotionListener()

+ mouseMoved(MouseEvent) : void

JPanel

TGLinkBrowser

+ arbolNodos: JTree

+ band: int = 0

+ bar: JScrollPane


- documentBase: URL










+ listReport: JList











~ tgPanel: TGPanel



~ xmlio: XMLio



- addUIs() : void






- jbInit() : void








+ TGLinkBrowser()




XMLio










+ read(URL) : void







~ml

~tgLinkBrowser

~mml

~xmlio

#lbEdgeDialog

Capítulo 6. Pruebas

El presente capítulo describe el plan de pruebas y su seguimiento para verificar la usabilidad de la metodología en la definición de estructuras de sitios Web basada en diseño de ontologías.


Página 86

6.1. Introducción

Este trabajo está enfocado al desarrollo de una metodología. Se presentarán únicamente las pruebas al editor que sirve para implementar la metodología propuesta y una pequeña prueba de usabilidad, utilizada más con propósitos de exploración que de validación

6.2. Hipótesis

Hipótesis nula a comprobar: se propone como hipótesis que a través de una metodología de construcción de sitios Web basada en principios de ontologías, se pueda agregar semántica a la estructura del sitio para que éste sea más fácil de comprender.

6.3. Prueba de usabilidad

6.3.1. Descripción de las pruebas

Para llevar a cabo las pruebas de usabilidad se tomarán en cuenta los siguientes pasos, basados en el test de guerrilla [Hassan 2003]: Desarrollo de la prueba: Para llevar a cabo las pruebas se proporcionó, a cada participante, un documento donde se describe la ontología, sus conceptos y relaciones, así como ejemplos del uso de los mismos. Esto se hizo con la finalidad de entrenar previamente al usuario antes del desarrollo de la prueba. Posteriormente se procedió a realizar una serie de preguntas en base a las características a probar, con lo que se obtuvieron datos sobre el desempeño de los participantes al momento de desarrollar sus tareas.

Rango de éxito Para la evaluación del rango de éxito obtenido se tomaron en cuenta las siguientes actividades:

Comprensión de la información sobre las clases: indica si el usuario tiene un

entendimiento de la taxonomía propuesta en la ontología. Las clases y subclases, así

como la manera en que un ejemplar puede catalogarse dentro de una clase definida.

Clasificación de ejemplares en las clases proporcionadas: se refiere a si el usuario es

capaz o no de clasificar un elemento de sitio Web (tipos de página) dentro de alguna

clase de las propuestas en la taxonomía.

Comprensión de la información de las relaciones: esta actividad reporta si el usuario

es capaz de entender el significado de las relaciones, así como la manera en que puede


Página 87

aplicarlas. Las restricciones que se presentan para cada relación y el modo en que las

características le ayudan a la construcción del sitio Web.

Etiquetado de enlaces con las relaciones propuestas: esta actividad reporta si el

usuario tiene la capacidad de elegir, de entre las múltiples relaciones, aquella que es

útil para enlazar dos nodos con características determinadas o si existen enlaces que

son imposibles de etiquetar pues no existe un modo de clasificarlas dentro de las

relaciones propuestas.

Facilidad de estructuración: se refiere a la facilidad que muestra el usuario al

momento de construir una estructura de sitio Web con los elementos proporcionados.

Comprensión de la estructura etiquetada: indica si el usuario es capaz de entender

mejor la estructura etiquetada con relaciones.

Actividad A B C D E F G

Comprensión de la información sobre las clases P P E E P E E Clasificación de ejemplares con las clases proporcionadas P P E E P P E Compresión de la información sobre las relaciones P P E E E E E Etiquetado de enlaces con las relaciones propuestas E E E E E E E Facilidad de estructuración E E E E E E E Comprensión de la estructura etiquetada E E E E E E E

Éxito parcial Éxito completo Rango de éxito (RE) Número de intentos para lograr las tareas (NI): 42 Número de éxitos parciales (NEP): 9 Número de éxitos completos (NEC): 33

6.3.2. Problemas encontrados

A partir de la prueba realizada se encontró una serie de inconsistencias en la ontología creada, lo que favoreció a su reestructuración y formalización.

Los detalles encontrados se listan a continuación:


Página 88

Los usuarios tenían dificultades para clasificar algunos ejemplares dentro de alguna

de las clases proporcionadas en la ontología, por lo que se dieron a la tarea de realizar

modificaciones a las mismas, de manera que se adecuaran a sus necesidades.

La mayoría de los usuarios pudo emplear las relaciones proporcionadas, aunque

algunos debieron leer varias veces la información de manera que quedara claro su

uso.

Algunos usuarios consideraron ambiguas las clases, lo cual generaba confusión al

momento de clasificar.

Para corregir las deficiencias presentadas se hizo la nueva clasificación, que se muestra en esta tesis, la cual incluyen ejemplos de instancias para las clases .Se agregó una descripción, características y restricciones para su aplicación, de modo que su uso fuera más claro.

6.4. Plan de pruebas

Los distintos casos de prueba para validar el funcionamiento del editor de sitios Web EDWEB se basan en el estándar IEEE 829 [Std829 07].

6.4.1. Características a probar

A continuación se listan las actividades desarrolladas durante la prueba:

Pruebas de creación y edición de grafos: se creará un grafo manual con componentes

de la ontología o automáticamente, indicando el archivo XML a partir del cual se

genera. Se verificará la correcta creación del grafo. Debe generarse un reporte de

enlaces no definidos, en caso de que existan.

Pruebas de creación de estructuras de sitios: se creará una estructura de un sitio Web

basada en un grafo creado previamente. La estructura contará con páginas enlazadas.

6.4.1.1. Pruebas de creación y edición de grafos

EDWEB-101 Pruebas de creación y edición de grafos.

EDWEB-101-001 Carga de la ontología.

EDWEB-101-002 Crear grafo del sitio Web.

EDWEB-101-003 Crear archivo XML a partir de un grafo.

EDWEB-101-004 Generar grafo a partir de un archivo XML.

EDWEB-101-005 Crear reporte de enlaces.

EDWEB-101-006 Validar estructura del sitio Web.


Página 89

6.4.1.2. Pruebas de creación de estructuras de sitios Web EDWEB-102 Pruebas de creación de estructuras de sitios Web.

EDWEB-102-001 Generar estructura del sitio Web.

6.4.2. Procedimiento de las pruebas

Este apartado contiene la descripción de los procedimientos correspondientes a cada caso de prueba propuesto en el plan de pruebas. Los casos se organizan en grupos para validar y verificar una determinada funcionalidad.

Los grupos de pruebas contienen tareas que se encargan de la validación y verificación de aspectos funcionales de la herramienta de software EDWEB. Para cada grupo de pruebas se describe el propósito del caso, el entorno de desarrollo del mismo, el procedimiento para llevar a cabo la prueba y los resultados que se obtienen a partir de ella. 6.4.2.1. EDWEB-101 Pruebas de creación y edición de grafos

Propósito Verificar la creación y modificaciones sobre grafos, así como el almacenamiento de datos y la visualización que se pueden realizar sobre ellos. Entorno de prueba PC o laptop

EDWEB-101-001 Carga de la ontología

Propósito Tener disponibles los componentes para la creación de grafos manuales (clases de la ontología). Entorno de prueba PC o laptop Proceso

Abrir el editor de estructuras de sitios Web, Seleccionar el archivo OWL de la ontología, Cargar las clases de la ontología contenidas en el archivo OWL.

Resultado esperado Las clases hoja de la taxonomía de clases que conforma la ontología se listan en un árbol que el usuario puede utilizar para la creación del grafo.


Página 90

EDWEB-101-002 Crear grafo del sitio Web

Propósito Crear un nuevo archivo descriptivo de un sitio Web que se visualiza como un grafo compuesto por clases y relaciones tomadas del conjunto de elementos propuestos. Entorno de prueba PC o laptop.

Proceso

Cargar la ontología. Seleccionar una clase de la lista y una relación del menú de relaciones. Elaborar una tripleta. Repetir el proceso de generación de tripletas hasta completar el grafo.

Resultado esperado

Es posible generar tripletas válidas de acuerdo a las restricciones dadas por la ontología.

Es posible visualizar el grafo cuando se genera.

EDWEB-101-003 Crear archivo XML a partir de un grafo

Propósito Guardar la estructura de datos XML del grafo creado manualmente para su posterior uso en la generación de la estructura de sitios Web. Entorno de prueba PC o laptop Proceso

Tras haber creado un grafo, seleccionar la opción de guardar el grafo. El archivo de la estructura del grafo se almacena en la carpeta de datos.

Resultado esperado

La estructura de datos XML se crea basándose en el archivo DTD.

La estructura de datos XML se almacena correctamente en la ubicación

deseada.

EDWEB-101-004 Generar grafo a partir de un archivo XML

Propósito Generar un grafo de sitio Web automáticamente a partir del archivo de datos XML que lo describe.


Página 91

Entorno de prueba PC o laptop Proceso

El usuario abrirá la aplicación. Elegirá una opción para abrir grafo existente. Seleccionará la carpeta que contiene el archivo deseado. La aplicación interpreta el archivo descriptivo. Se generará el grafo.

Resultado esperado Se genera un grafo etiquetado con relaciones definidas por el archivo XML o con relaciones indefinidas, donde los nodos representan a las páginas HTML y las aristas a los enlaces entre ellas.

EDWEB-101-005 Crear reporte de errores

Propósito Verificar que los enlaces entre los nodos del grafo tengan relaciones definidas. Entorno de prueba PC o laptop Proceso

Ejecutar la aplicación. Tras haber creado un nuevo grafo o seleccionar uno existente, seleccionar del

menú la opción para verificar grafo. Reportar tripletas inconsistentes en el grafo.

Resultado esperado

Se despliega el mensaje de grafo relacionado correctamente.

Se genera el reporte que indica inconsistencias en ciertas tripletas del grafo.

EDWEB-101-006 Validar estructura del sitio Web

Propósito Mostrar al usuario de manera visual que el grafo es inconsistente en algunos de sus elementos. Entorno de prueba PC o laptop Proceso

Ejecutar la aplicación. Crear un nuevo grafo o abrir un grafo existente.


Página 92

Los elementos inconsistentes como aristas indefinidas o nodos sin etiquetas se visualizan de un tono magenta.

Resultado esperado

Los conceptos y relaciones indefinidos se visualizan de color magenta.

6.4.2.2. EDWEB-102 Pruebas de creación de estructuras de sitios Web

Propósito Revisar que sea posible generar un conjunto de páginas basadas en un grafo del sitio Web. Entorno de prueba PC o laptop.

EDWEB-102-001 Generar estructura del sitio Web

Propósito Verifica que después de revisar la estructura, sea posible crearla correctamente. La estructura debe contener un conjunto de páginas. Entorno de prueba PC o laptop. Proceso Abrir el editor de estructuras de sitios Web. Crear un nuevo grafo o abrir uno existente. Ejecutar el caso EDWEB-101-005 Reportar enlaces indefinidos para revisar los enlaces en el grafo del sitio. Seleccionar del menú la opción para generar HTML y crear la estructura. Resultado esperado Se creará una estructura del sitio Web, con un conjunto de páginas enlazadas entre sí.

6.4.3. Resultados de las pruebas

En este apartado se muestran algunos ejemplos de aplicación de la metodología a través de la herramienta EDWEB. Se presentan los resultados de cada caso de prueba con un escenario de éxito en las pruebas desarrolladas.


Página 93

Tabla 6.1. Caso de prueba EDWEB-101-001 Carga de la ontología

Caso de prueba: EDWEB-101-001 Carga de la ontología

Resultado: OK Archivo OWL seleccionado

Conjunto de clases listadas:

Observaciones: es posible cargar cualquier ontología almacenada en un archivo OWL, lo que permite observar las clases hijas de dicha ontología en forma de lista. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.


Página 94

Tabla 6.2. Caso de prueba EDWEB-101-002 Crear un grafo manual

Caso de prueba: EDWEB-101-002 Crear un grafo manual

Resultado: OK Formación de tripleta

Observaciones: Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.

Tabla 6.3. Caso de prueba EDWEB-101-003 Generar un archivo XML

Caso de prueba: EDWEB-101-003 Generar un archivo XML

Resultado: OK Selección de menú

Clase

Ejemplar

Relación

Guardar grafo


Página 95

Archivo a guardar

Archivo XML generado

Nombre del archivo


Página 96

Observaciones: los conceptos deben tener un nombre al momento de ser guardados, ya que esto repercute en el momento de la creación de una estructura basada en el grafo. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.

Tabla 6.4. Caso de prueba EDWEB-101-004 Generar un grafo automáticamente

Caso de prueba: EDWEB-101-004 Generar un grafo automáticamente

Resultado: OK Selección de menú

Archivo a graficar

Grafo generado a partir del archivo

Abrir grafo existente

Archivo

Grafo


Página 97


Tabla 6.5. Caso de prueba EDWEB-101-005 Reportar enlaces indefinidos

Caso de prueba: EDWEB-101-005 Reportar enlaces indefinidos

Resultado: OK Grafo con etiquetas indefinidas en las aristas

Reporte de tripletas indefinidas

Observaciones: se valida únicamente el uso de relaciones válidas, aunque pudieran considerarse algunas otras características definidas en la metodología. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.

Grafo

Tripletas indefinidas


Página 98

Tabla 6.6. Caso de prueba EDWEB-101-006 Validar el grafo

Caso de prueba: EDWEB-101-006 Validar el grafo

Resultado: OK Grafo correctamente etiquetado

Edición de una arista para mostrar la etiqueta indefinida

Valor indefinido

para la arista

Arista resultante


Página 99

Nodo con etiqueta


Tabla 6.7. Caso de prueba EDWEB-102-001 Generar estructura del sitio Web

Caso de prueba: EDWEB-102-001 Generar estructura del sitio Web

Resultado: OK Grafo etiquetado

Valor indefinido

para el nodo


Página 100

Carpeta creada para el grafo etiquetado

Ejemplo de página con enlaces

Observaciones: una relación indefinida no afecta en la creación de la estructura, pero sí la falta de definición de los ejemplares. Responsable de la prueba: Matilde Baños Nolasco Cargo: autora.


Página 101

La tabla 6.8 muestra una descripción de los grafos para los casos de prueba de la herramienta EDWEB.

Tabla 6.8. Descripción de grafos de los casos de prueba de la herramienta EDWEB Caso de prueba Nodo origen Nodo destino Relación

EDWEB-101-002 UnidadOrganizacional: * UnidadOrganizacional: Principal (F) Meronimia canónica-canónica

EDWEB-101-004 UnidadOrganizacional: Departamento CC

DescripciónAbstracta: Presentación


UnidadOrganizacional: Departamento CC

UnidadOrganizacional: Sistemas Distribuidos



DescripciónFísica: Infraestructura (G) Meronimia canónica-canónica


UnidadOrganizacional: PersonalAcadémico


EDWEB-101-005 UnidadOrganizacional: Principal OrganizaciónFuncionamiento: Departamento de CC

Indefinida

OrganizaciónFuncionamiento: Departamento de CC

Trabajador: Dr. Juan Gabriel Indefinida

OrganizaciónFuncionamiento: Departamento de CC

Trabajador: Dr. José Antonio Indefinida

EDWEB-101-006 UnidadOrganizacional: SistemasDistribuidos

UnidadOrganizacional: Posgrado (F) Meronimia canónica-canónica

UnidadOrganizacional: SistemasDistribuidos

UnidadOrganizacional: Publicaciones


UnidadOrganizacional: Posgrado OrganizaciónFuncionamiento: Plan de estudios

(E) Meronimia canónica-canónica

UnidadOrganizacional: Publicaciones

Producto: Artículo (D) Meronimia colección-miembro


UnidadOrganizacional: Posgrado Indefinida


Servicio: * Indefinida

EDWEB-102-001 Grafo del caso EDWEB-101-004

Nota: * denomina un nodo sin nombre de ejemplar definido.

Capítulo 7. Conclusiones Este capítulo resume las conclusiones obtenidas como resultado de la investigación, las aportaciones y propuestas de trabajos que podrían derivarse en el futuro a partir de de la metodología desarrollada.

Capítulo 6. Conclusiones

Página 103

7.1. Conclusiones

A continuación se listan las conclusiones obtenidas a partir de la investigación realizada:

1. No se encontraron otras herramientas o metodologías que permitan establecer

semántica a la estructura de un sitio Web, por lo cual este trabajo es pionero en su

campo. Las herramientas analizadas proveen patrones de diseño referentes a la

estética del sitio, otras herramientas se basan en el contenido de las páginas para

generar aplicaciones Web, mejorando la explotación de la información.

2. Se encontraron trabajos donde se expresa que existen relaciones implícitas en la

estructura de un sitio Web, siendo éstas de asociación y de agregación. Sin embargo,

no se define claramente ni se fundamenta su uso, ni los casos en que es posible

utilizarlas, ya que no se aplican de manera práctica.

3. Es posible relacionar conceptos en sitios Web del dominio de educación con relaciones

léxicas, entre ellas una de interés particular fue la meronimia. Algunos problemas

presentados con los tipos de meronimias encontrados se refieren al hecho de que es

posible aplicarlos en entidades tangibles, siendo difícil relacionar objetos abstractos

como los que representan algunas páginas, por lo que fue necesario integrar ciertas

propiedades que permitieran una adaptación de los tipos encontrados.

4. Los metadatos que se propone se agreguen a las páginas HTML (por ejemplo, autor,

tema, entre otras), no son suficientes para describir la estructura de un sitio Web.

7.2. Aportaciones

El trabajo que se presenta en esta tesis ofrece dos aportaciones: a) una definición de conceptos acerca de la arquitectura de sitios Web que se encuentran en el dominio de educación; b) proporciona un enfoque del uso del diseño de ontologías dentro de esta área.

7.3. Trabajos futuros

El trabajo de investigación presentado comprende el desarrollo de una metodología genérica que permite la creación de estructuras de sitios Web, así como su implementación en una herramienta de edición de sitios Web a través del uso de grafos. Algunas propuestas de trabajos que podrían desprenderse de esta tesis se listan a continuación:

Encontrar nuevos patrones de diseño, conceptos y relaciones que ayuden en el

enriquecimiento de la ontología propuesta, de manera que su uso pueda compartirse

a otros dominios de sitios Web o aplicaciones.

Automatizar el proceso de creación de la ontología, ya que la obtención de los

conceptos y relaciones fue un proceso manual que comprendió un periodo de cuatro

Capítulo 6. Conclusiones

Página 104

meses aproximadamente. Es posible obtener una automatización de una buena parte

de la creación de la ontología que aminore el tiempo de análisis y proporcione un

mayor contenido de información a través del estudio del contenido de sitios Web.

Realizar un estudio semántico que permita nombrar las relaciones y conceptos de

manera que brinden al usuario un mayor grado de comprensión.

Automatizar la generación de grafos de sitios Web, a través del análisis del contenido

de los documentos que lo componen, de manera que el etiquetado no se realice de

forma manual, cuando se necesite representar sitios con un gran número de páginas.

De esta manera se disminuye el tiempo y esfuerzo de operación de la herramienta.

7.4. Publicaciones

“Adapting Meronymy Relation to Define Properties among Web Site Objects”, presentado en The Fifteenth International Multi-Conference on Advanced Computer Systems (ACS 2008), a publicarse en Polish Journal of Environmental Studies, en Polonia. Indexado por el Science Citation Index SCI.

Anexo A: Ejemplos de etiquetado

Los ejemplos de etiquetado mostrados a continuación fueron creados en base sitios de educación. Para una mejor comprensión de la estructura de los sitios Web se ha realizado el etiquetado por secciones.

A.1 Fragmento de grafo de la página principal del cenidet

Dominio Nodo del dominio

Rango Nodo del rango Relación

Unidad organizacional

Cenidet Unidad organizacional

Ingeniería Mecánica




Ingeniería Mecatrónica




Ingeniería Electrónica




Ciencias Computacionales



Cenidet Descripción abstracta

Presentación (K) Meronimia canónica-facultativa


Cenidet Descripción física

Directorio (A) Meronimia facultativa-facultativa


Cenidet Descripción física

Localización y traslado



Cenidet Suceso Curso de actualización

Topológica

A.2 Fragmento de grafo del departamento de Física del CINVESTAV

Dominio Nodo del

dominio Rango Nodo del rango Relación


Departamento de Física


Programa de maestría en ciencias (Física)




Descripción abstracta

Principal A) Meronimia facultativa-facultativa



Descripción física

Directorio A) Meronimia facultativa-facultativa



Descripción física

Ubicación A) Meronimia facultativa-facultativa




Investigadores (I) Meronimia canónica-canónica


Investigadores Trabajador Baquero Parra, Rafael



Investigadores Trabajador Bretón Báez, Nora Eva


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;

...

}

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);

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) {

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;

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);

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();){



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);

for (Enumeration edgeEnum = edgeSet.enumerateChildren();

edgeEnum.hasMoreElements();){



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();){



...

}

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",

"Error", JOptionPane.WARNING_MESSAGE);

Global.globalCont=contNodes;

}

for (Enumeration edgeEnum = edgeSet.enumerateChildren(); edgeEnum.hasMoreElements();){


String edgeLabel= edge.getAttribute("label","");

if (edgeLabel.equals("Indefinida")){


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);

}

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());

...

}

...

}

Referencias [ADOBE 07] Adobe; [En línea]; [Accedido el 21 de septiembre de 2007]; Disponible en:

“http://livedocs.adobe.com/dreamweaver/8_es/using/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=05_sit27.htm”.

[BRAIN 04] TheBrain Technologies Corporation; The Brain, Personal Brain. User guide; 2004; [En línea]; [Accedido el 21 de septiembre del 2007]; Disponible en: “http://www.thebrain.com/site/personalbrain/support/PersonalBrain_3_02_User_Guide.pdf”.

[BRAIN 07] The Brain. Visual Information Management; [En línea]; [Accedido el 17 de junio del 2007]; Disponible en línea en el World Wide Web en: “http://www.thebrain.com/#-42”.

[CAÑAS 03] Cañas A. J., Coffey J. W., Carnot M. J., Feltovich P. J., Hoffman R. R, Novak J. D.; “A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support”; Technical Report submitted to the US Navy Chief of Naval Education and Training; Institute for Human and Machine Cognition (IHCM); Pensacola, Florida; july 2003.

[COOLEY 00] Cooley R., Tan P., Srivastava J.; “Discovery of interesting usage patterns from Web data”; Lecture notes in computer science: Web usage analysis and user profiling 1836/2000; ISSN 0302-9743 (Print) 1611-3349 (Online), pp. 163-182; 2000.

[CRUSE 86] Cruse D. A; “Lexical Semantics”; Cambridge University Press; 1986. [DÍEZ 99] Díez P.L.; “La relación de meronimia en los sustantivos del léxico español:

contribución a la semántica computacional”, Estudios de lingüística española, 2; ISSN 1139-8736; 1999.

[FONS 02] Fons J. J., Pastor O., Valderas P., Ruiz M.; 2002; “OOWS: un Método de Producción de Software en Ambientes Web”; Avances en Comercio Electrónico 9; ISBN 84-607-5827-3; pp. 119-136.

[GUIZZARDI 05] Guizzardi G; Ontological foundations for structural conceptual models; Telematica Instituut Fundamental Research Series No. 15; ISBN 90-75176-81-3 ISSN 1388-1795, No. 015. CTIT PhD-thesis; ISSN 1381-3617, No. 05-74; 2005.

[GREENWICH 07] University of Greenwich; Website Arquitecture, Masters Programme at the University of Greenwich, [En línea]; [Accedido el 15 de abril de 2007]; Disponible en: http://www.Websitearchitecture.co.uk/define/index.php.

[GRUBER 93] Gruber T.; “A Translation Approach to Portable Ontology Specifications”; Knowledge Acquisition 5(2); ISSN: 1042-8143; pp. 199-220, 1993.

[HASSAN 03] Hassan M., Martín F., Método de test con usuarios, 2003; [En línea]; [Accedido el 05 de agosto de 2008]; Disponible en: “http://www.nosolousabilidad.com/articulos/test_usuarios.htm”.

[IHCM 07] Institute for human and machine cognition (IHCM) CmapTools; [En línea]; [Accedido el 15 de abril de 2007]; Disponible en: “http://cmap.ihmc.us/”.

[INSFRÁN 98] Insfrán E., Pelechano V., Gómez J., Pastor O.; “Un estudio comparativo de la expresividad de relaciones entre clases en OO-Method y UML”, III Jornadas de Trabajo de MENHIR; Murcia, España; noviembre, 1998.

[JIN 01] Jin Y., Decker S., Wiederhold G.; “OntoWebber: Model-Driven Ontology-Based Web Site Management”; The 1st International Semantic Web Working Symposium (SWWS'01); Universidad de Stanford, Palo Alto, California; julio 29-agosto 1, 2001.

[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.

[USCHOLD 96] Uschold M., Gruninger M.; 1996; “Ontologies: principles, methods and applications”; Knowledge Engineering Review 11; No. 2; pp 320-321.

[W3C 08] W3C. Semantic Web; [En línea]; [Accedido el 27 de marzo de 2008]; Disponible en: “http://www.w3.org/2001/sw/”.

[W3C 08b] Extensible Markup Language; [En línea]; [Accedido el 27 de junio del 2008]; Disponible en: “http://www.w3.org/XML/”.

centro nacional de investigación y desarrollo tecnológico20matilde%… · resumen los sitios web...

Documents