-
 
Cuando hablamos del concepto de arquitectura de un hipertexto, nos
referimos a la estructura de un modelo que tiene como fin describir un sistema
teórico de hipertexto, aunque ciertos criterios son también
válidos para ser aplicados al software de la creación de hipertextos, y no
sólo al sistema como concepto abstracto.
Es ya clásica la teorización sobre la existencia de distintos niveles o
capas para configurar un modelo de hipertexto y poder hablar con propiedad de la
arquitectura hipertextual como abarcadora de una serie de perspectivas
distintas: física, lógica, de presentación de la información, de
organización interna de la información, de organización semántica del
contenido, de interfaz o presentación de ésta al usuario, etc.
Hay
muchas y diferentes visiones de la arquitectura de un sistema hipertextual. Los
modelos conceptuales abstractos de los sistemas de hipertexto son a
menudo denominados "Modelos de Referencia". Estos modelos se
crearon con el fin de establecer unas normas para hacer posible el intercambio
entre sistemas hipertextuales distintos, ya que los
sistemas más comunes eran sistemas cerrados que no podían ser integrados en
otros y, como afirmaba Van Dam,
esta falta de compatibilidad, conectividad y de normas comunes, creaba
"docu-islas" de conocimiento incompatibles. Para facilitar la integración y hacer posible la conversión entre unos
sistemas y otros, los investigadores del hipertexto comenzaron a trabajar, ya
desde los inicios del hipertexto, en estos modelos abstractos.
Según Afrati,
el objetivo de un modelo debe ser la representación conceptual de un tipo de
tecnología y no de un sistema en particular. Un modelo es, pues, un marco teórico que formaliza todas las características y
funciones, esenciales o deseables, que se puedan incluir en cualquier aplicación
hipertextual. Para Tompa,
un modelo en el contexto de los sistemas hipertextuales, debe ser capaz de
representar tanto la estructura estática como el funcionamiento dinámico de
sus componentes.
Los dos modelos de referencia más conocidos y que configuran una división por
niveles en la arquitectura de un sistema de hipertexto son:
Sin embargo, existen otros muchos modelos de referencia que describen los
elementos conceptuales de los sistemas de hipertexto. Como estos modelos describen los elementos conceptuales posibles, a veces
no se han desarrollado en la práctica. Muchos sistemas lo que han hecho ha sido
ampliar y profundizar en algunas partes de los modelos clásicos de Dexter o HAM.
Podemos destacar los siguientes:
Los
recientes modelos que están desarrollándose, incorporan
el paradigma de la orientación a objetos con el fin de mejorar las prestaciones
de los sistemas de hipertexto e hipermedia. Esto lo hacen mediante el uso de
Sistemas de Gestión de Bases de Datos Orientados a Objeto (SGBDOO) para
almacenar la información heterogénea, aplicando alguna norma estándar para estructurar
el contenido de un hiperdocumento y adoptando un enfoque de ingeniería de
software con el fin de diseñar un modelo previo que recoja las necesidades de
los usuarios. Un modelo orientado a objetos
permite una representación gráfica del hipertexto para representar la
estructura estática de la información, un modelo dinámico para los aspectos
temporales del comportamiento del sistema y un modelo funcional para representar
los procesos que transforman la información del sistema. Lo normal es utilizar
software de autor o
herramientas de edición para crear hipertextos, pero es
preciso antes un análisis conceptual tanto de los elementos estructurales, como
de la navegación y de la interfaz que se le presentará al usuario.
Tras la explosión de las distintas notaciones y
modelos para el diseño orientado a objetos, se ha desarrollado un
lenguaje que
pretende unificar todas las notaciones y diagramas estándar para modelar
sistemas orientados a objetos y que describe la semántica esencial de
estos diagramas y los símbolos en ellos utilizados. Se trata del
lenguaje UML o Lenguaje Unificado de Modelado.
Por lo general, los
modelos de hipertexto/hipermedia tienen en cuenta una serie de aspectos:
-
Nivel de Usuario, que trata de los mecanismos de autoría de
hipertextos, interfaz de usuario, navegación y diseños de libros electrónicos
-
Nivel Conceptual, que desarrolla la problemática de la autoría de
hipertextos en colaboración y la presentación de algunos modelos de diseño
de hiperdocumentos
-
Nivel Físico, donde realizan una exposición de los aspectos de
almacenamiento de la información y lenguajes de marcas para
hiperdocumentos.
-
Aplicaciones de la hipermedia, introduciendo los sistemas y
herramientas de hipermedia
Lo comúnmente aceptado hoy es hablar de la arquitectura de
un sistema de hipertexto en 3 niveles:
-
Nivel de presentación o interfaz de usuario:
que comprende los elementos de acceso a la información, ayudas, niveles de
acceso (autor, lector), herramientas de navegación y diseño homogéneo de todo
el sistema. Este nivel está estrechamente relacionado con el nivel HAM, ya que
la organización de la información determina en gran parte las posibilidades de
presentación.
-
Nivel HAM (Hypertext Abstract Machine):
se
trata del centro de la arquitectura general de un sistema de hipertexto y es
el nivel que establece la estructura y naturaleza básica de los
nodos y enlaces, sus
relaciones y atributos.
-
Nivel de Base de Datos: es el nivel donde se
contiene todo lo referente al almacenamiento de la información, esto es,
estructura de archivos, códigos de identificación, herramientas de control,
acceso y restricciones de usuarios, etc.
Estos modelos fueron
establecidos para herramientas de hipertexto independientes y hay que tener en
cuenta que si estos conceptos se quieren llevar a la práctica en ámbitos tales
como la Web o la conversión de Bases de Datos (Documentales o Relacionales) en
estructuras de hipertexto, debemos considerar que la World Wide Web
es una aplicación construida en base a un modelo hipermedial muy
restrictivo ya que no admite compuestos (grupos de nodos), no tiene enlaces
n-arios, no tiene enlaces bidireccionales, no hay soporte para visitas guiadas y
prácticamente no existe metainformación semántica asociada a los
nodos, y mucho
menos a los enlaces.
Por ejemplo, el contenido semántico de la red de
nodos en la
Web es muy
bajo y, por el contrario, la mayoría de los modelos hipermedia usados en aplicaciones incluyen más cosas que sólo
los enlaces tipo página web.
Hoy los modelos de
hipertexto son muy complejos, puesto que además de objetos
hipermedia, para la presentación e
interfaz de usuario, incluyen una interfaz de Objetos de Acceso de Datos
para facilitar la conectividad con bases de datos e intercambio de información y
una interfaz de programación de aplicaciones API (Application Programming interface). Todos estos aspectos se estudiarán en el apartado relativo a
Bases de datos.
En cuanto al
contenido hipermedia, la práctica común actualmente es utilizar modelos de
diseño. La idea
de utilizar modelos de diseño proviene de muy antiguo, aunque fue adoptada por
un grupo de investigadores en el área de orientación a objetos y en 1997 se
comenzó a trabajar en el problema de representar objetos como documentos hipermediales. Hoy existen gran número de patrones hipermedia tales como:
-
Patrones de
interfaz
-
Agrupamiento de comportamiento,
información-interacción: patrones que se relacionan con cómo separar los
elementos sobre los cuales el usuario puede realizar una
acción de aquellos que tienen contenido informacional, y los de interacción
entre sí.
-
Otros patrones: índice navegable,
selección del espacio de búsqueda, etc.
-
Patrones de estructura y navegación
-
Visitas guiadas, mapas de navegación,
etc.
-
Plantillas de presentación con
diagramación para portadas, índices de contenidos, artículos en ventana,
formularios, resultados de búsqueda, etc.
-
Cajas de contenido, etc.
El criterio de hiperización varía según
el método elegido. En el modelo Trellis se trata de la estructura navegacional
y de los mecanismos de sincronización, en el modelo EORM se trata de las relaciones
y para los modelos orientados a objetos se trata de estructuras de datos. Hoy se siguen diseñando otros modelos y
herramientas que permitan mezclar el dominio hipermedia con otros
dominios. Lo que es cierto es que
cada uno de los modelos que se han desarrollado y que se expondrán a
continuación, se ha interesado más
por un determinado aspecto, aunque todos ellos son fundamentales para establecer
un modelo de hipertexto y llevarlo a la práctica.
El
Modelo Dexter
El objetivo básico del modelo Dexter fue proporcionar una base sistemática para
comparar distintos sistemas de hipertexto y desarrollar normas de intercambio e
interfuncionalidad. El modelo divide el hipertexto en tres capas:
-
Capa
de ejecución: se ocupa de la presentación del hipertexto y de la dinámica
de la interacción con el usuario. No entra en detalles sobre dicha
presentación, sino que provee especificaciones que ponen en relación esta capa
con la capa de almacenamiento.
-
Capa
de almacenamiento: constituye la capa principal. Consta de componentes que
contienen datos conectados mediante enlaces. Los componentes equivalen a
nodos y pueden contener textos,
imágenes, audio o
vídeo. Todos
estos elementos son tratados como contenedores genéricos,
independientemente de su contenido. El modelo se centra en la forma en que
se relacionan los componentes y los enlaces para formar una
red hipertextual.
-
Capa de los
componentes: se ocupa del contenido y la estructura de los componentes de la
red de hipertexto, puede ser usada en conjunción con modelos de estructura
de documentos como SGML.
(Para ampliar y
profundizar en el modelo, ir a Modelo Dexter) El modelo HAM o
Hypertext Abstracts Machine
El
modelo HAM fue creado por Campbell y Goodman en 1988. Es un modelo centrado en
el almacenamiento, provee un sistema general y flexible que puede usarse en
diferentes aplicaciones de hipertexto.
Consta
de 3 niveles o capas:
Consiste
en cinco tipos de objetos principales: gráficos (redes de nodos y
enlaces que
contengan uno o más contextos), contextos (partición de datos con un gráfico),
nodos, enlaces y atributos. Se pueden realizar 7 operaciones básicas, crear,
borrar, eliminar, cambiar, tomar, filtrar y especiales. La arquitectura HAM
proporciona control de versión, filtro y seguridad de los datos y fue usada
con éxito en sistemas como Guide,
Intermedia y
NoteCards.
En
realidad, el modelo HAM no difiere en exceso del modelo Dexter,
la diferencia está en una serie de matices a la hora de definir los niveles
intermedios. En el modelo Dexter se
confiere una especial atención a lo que se denomina focus que, en cierto
modo, es perfectamente equiparable a la HAM del modelo de 3 niveles. De hecho,
las especificaciones para la presentación de los documentos y cómo se
organizan los enlaces entre los nodos, constituyen elementos básicos e
imprescindible de la HAM. El
contenido de los nodos (la información de nivel físico), reside en el nivel
inferior, como en el modelo anterior y también la interfaz de presentación de
la aplicación al usuario, es de similar concepción en ambos modelos.
(Para ampliar y profundizar en el modelo, ir a Modelo
HAM) El modelo Amsterdam
El
modelo de Amsterdam extiende el modelo de Dexter añadiendo
las nociones de tiempo, presentación a alto nivel de atributos y enlaces de
contexto. Es el primer modelo que tiene en cuenta la complejidad de los tipos
multimedia y el tratamiento de la cuestión del tiempo que conllevan, por
ejemplo, el audio o el vídeo.
(Para ampliar y profundizar en el modelo, ir a Modelo
Amsterdam)
El
modelo de Trellis
El
modelo Trellis, ideado por Stotts y Furuta en 1990 consideraba varios niveles de
abstracción dentro de los sistemas de hipertextos:
-
Nivel
abstracto: esta capa contiene componentes independientes definidos
especulativamente y conectados de cierta manera. Este nivel puede
normalizarse usando los protocolos de intercambio de documentos, tales como
SGML.
-
Nivel
concreto: en el que se establecen las características de la pantalla física
del hipertexto. Es decir, se especifica el contenido de cada ventana, pero
no se desarrolla
-
Nivel visible:
capa responsable de la visualización.
Y así, habría
que tener en cuenta diferentes aspectos como:
-
el contenido de la información,
-
la estructura navegacional
-
y el control navegacional (esto es, el control de la
dinámica de la aplicación).
(Para ampliar y
profundizar en el modelo, ir a Modelo
Trellis Modelo
Formal de Lange
El
modelo formal, fue desarrollado por Danny B. Lange en 1990, basándose en el
lenguaje Vienna Development Method. El modelo formal se centraba en la estructura
de datos de un hipertexto, que llama modelo de datos del hipertexto. Este modelo
de datos define nodos, enlaces,
estructuras de red, etc. El modelo de datos básico
se puede ampliar para convertirse en un modelo orientado a objetos, pero como
está muy centrado en el modelo de datos y en la información textual, es poco
útil para describir sistemas hipermedia.
(Para ampliar y
profundizar en el modelo, ir a Modelo Formal)
Modelo
Tower o Torre
El
modelo Torre o Tower, fue ideado por De Bra, Houben y Kornatzy, y presentado en
la 4ª Conferencia sobre Hipertexto en 1992. Era un sistema orientado a objetos
en el que los elementos básicos son cajas negras. Permite valores de diferentes
objetos de datos pertenecientes a diversos tipos.
El
modelo cuenta con unos elementos estructurales básicos que son:
nodos, enlaces y
anclas, objetos torre y objetos ciudades. Los objetos
torre
sirven para modelar diferentes descripciones de un objeto y tienen diferentes
niveles: tipo, estructura de almacenamiento, presentación, etc. Las ciudades
representan conjuntos de visualizaciones de "objetos torre".
El
modelo permite que cualquier clase de objeto se convierta en un objeto virtual.
Los operadores para definir una estructura virtual son "Aplicable a todos",
"Filtro", "Enumeración" y "Abstracción o agrupamiento". La semántica
de visualización se describe a través de "trayectorias", que se definen
usando axiomas "espacio-temporales".
(Para ampliar y
profundizar en el modelo, ir a Modelo Tower) Modelo HDM:
Método de Diseño de Hipermedia
El
proceso de diseño de una aplicación en HDM
(Hypertext Design Model), se divide en dos partes:
-
authoring
in the large: para referirnos a la especificación y diseño de los
aspectos globales, estructurales de la aplicación
-
authoring
in the small: para referirnos al desarrollo del contenido de los
nodos.
El
modelo, se centra en la primera, en los aspectos globales y estructura de la
aplicación.
La
terminología de HDM difiere de la del modelo de Dexter ya que el equivalente a
nodo aquí se denomina unidad. Las unidades se agrupan mediante una
visita guiada o un índice, formando componentes, que a su vez se agrupan
jerárquicamente en lo que denominan entidades.
En este
modelo se diferencian varios tipo de enlaces:
HDM se presenta también como un modelo muy
útil para evaluar aplicaciones, lo que se ha venido en denominar evaluación
orientada al diseño. HDM
es más que un intento de modelar la estructura del hipertexto-hipermedia, pues
también se trata de una modelización de las estructuras de navegación que
permite también hacer un análisis posterior de la estructura y de los
mecanismos de navegación.
(Para ampliar y
profundizar en el modelo, ir a Modelo HDM)
RMM (Metodología de Administración de Relaciones)- RDMD
(Modelo de Datos de Administración de Relaciones)
El modelo RMM (Relationship Management Methodology),
no es únicamente un modelo de datos, sino una metodología completa que define
las fases de todo el proceso de creación de un hipertexto/hipermedia. Se basa
en un modelo de entidad-relación en donde se añaden unas primitivas. En
este modelo destaca el concepto de "slice", que permite agrupar datos de
una entidad en diferentes pantallas, ya que cuando existen diferentes medios, la
información de una entidad puede ser muy variada. Por ejemplo, pueden mostrarse
varios vídeos distintos sobre una conferencia de hipertexto en
pantallas diferentes según sea el conferenciante. Otro término utilizado en este modelo
es la primitiva de grupo, que permite hacer explícita la jerarquía de
menús.
(Para ampliar y
profundizar en el modelo, ir a Modelo RMM)
Modelo
OOHDM (Método de Diseño de Hipermedia
Orientado a Objetos)
OOHDM (Object Oriented Hypermedia
Design Methodology) es una extensión de HDM con orientación a
objetos, que se ha convertido en una de las metodologías más utilizadas.
Lo que le distingue de RMM es el proceso de concepción
orientado a objetos. OOHDM tiene cuatro etapas, cada una centrada en un
aspecto de la concepción.
Cada etapa define un
esquema objeto específico en el que se introducen nuevos elementos (clases). En
la primera etapa, el análisis del dominio consiste en establecer un esquema
conceptual en términos de clases, relaciones y subsistemas. En la segunda etapa, el diseñador define
clases navegacionales tales como nodos,
enlaces, índices y visitas guiadas
inducidas del esquema conceptual. Los
enlaces derivan de relaciones y los
nodos representan ventanas lógicas (views) sobre las clases conceptuales. A
continuación, el diseñador describe la estructura navegacional en términos de
contextos navegacionales. Estos contextos definen agrupaciones -en el sentido de
HDM- de objetos navegacionales (nodos,
enlaces,....). Durante esta etapa, es
posible adaptar los objetos navegacionales para cada contexto, de forma similar
a las perspectivas de HDM. La tercera etapa, dedicada a la especificación del
interfaz abstracto, describe los objetos de interfaz y los asocia con objetos de
navegación. Por fin, la última etapa, consagrada a la implementación, hace
corresponder los objetos de interfaz con objetos de implementación.
(Para ampliar y
profundizar en el modelo, ir a Modelo OOHDM)
Modelo EORM:
Metodología de Relaciones de Objeto Mejorada
El método EORM (Enhanced Object-Relationship Model), se define como un proceso más o menos informal
de concepción de sistemas de información dotados de funcionalidades
hipermedia.
Para ello, tras un determinado proceso, se llega a elaborar una serie de
esquemas EORM que sirvan
de especificación para la concepción de aplicaciones.
Los esquemas EORM se constituyen a partir de
un modelo conceptual completado con clases de enlaces que especifican sus
aspectos estáticos y dinámicos. Se proponen clases tipo aunque el diseñador
define preferiblemente clases enlace "ad-hoc", según sus necesidades. Este
aspecto constituye la filosofía y característica principal de EORM.
La primera etapa consiste en un análisis del
sistema con la ayuda de un método orientado a objetos que define la
estructura de las informaciones (modelo objeto), su comportamiento (modelo dinámico)
y sus interrelaciones.
La segunda etapa consiste en crear el esquema
EORM de la aplicación a partir de los elementos proporcionados por la etapa
anterior. Este esquema especifica las relaciones de interacción de la aplicación,
en donde las relaciones entre objetos son vistas como caminos de interacción
semánticamente ricos (es decir, que tienen una estructura y un comportamiento),
más que como simples relaciones estructurales.
De esta forma, las relaciones definidas en un
modelo orientado a objetos pueden ser representadas por clases de enlaces hipermedia.
Estas clases añaden a las relaciones del modelo objeto la semántica
navegacional de la aplicación. Están organizadas en una jerarquía de herencia
propuesta por el método bajo la forma de una biblioteca de clases. La semántica
relativa a las propiedades hipermedia de las relaciones encuentra, por tanto,
una representación en EORM bajo la forma de clases.
Finalmente, la tercera etapa consiste en
transformar los esquemas EORM en código y guardarlos en una Base de
Datos Orientada a Objetos, y en elaborar formularios de consulta de las clases
con la ayuda de un editor gráfico de interfaces.
Toda la semántica de las
relaciones de la aplicación se expresa por medio de enlaces hipermedia
reagrupados en una jerarquía de clases y así, el comportamiento definido sobre los enlaces permite tener en cuenta una parte de
la semántica de la navegación de la aplicación. También se permite alterar la
propia estructura navegacional de la aplicación mediante operaciones de creación,
destrucción o de modificación de elementos hipermedia. El modelo EORM se ha
centrado, principalmente, en el
enriquecimiento de los elementos hipermedia.
UML
Aunque no se trata de un modelo, sino de todo un lenguaje para modelar distintos
tipos de sistemas, se ha decidido incluir aquí, y no en el capítulo referido a
los lenguajes hipertextuales, el lenguaje UML (Unified
Modeling Language) Lenguaje Unificado de Modelado. El UML prescribe un
conjunto de notaciones y diagramas estándar para modelar sistemas orientados a
objetos y describe la semántica esencial de estos diagramas y los símbolos en
ellos utilizados.
En la programación orientada a objetos, algunos conceptos
claves son: objetos, atributos, métodos, clase, etc.
Se puede definir un objeto como un conjunto de datos y
funciones relacionadas. Las funciones de los objetos son los métodos y los datos
son los atributos. De esta forma, los objetos en programación se modelan
observando objetos del mundo real y definiendo los atributos y métodos de dicho
objeto.
Una clase es algo abstracto que define la "forma" del objeto,
algo así como el molde de los objetos. Por ejemplo, un libro determinado es sólo
uno de todos los libros de una biblioteca, por lo tanto, un libro es una
instancia de la clase "Libro". Todos los libros tienen los atributos:
título, autor, edición, etc. y métodos: abrir, cerrar, ir a la página siguiente,
ir a la página anterior, etc.
La programación orientada a objetos permite producir objetos
en serie por medio de clases o moldes, y así utilizaremos la clase libro (molde)
para producir sus instancias (objetos). Los objetos son instancias de clases.
La clase es, pues, una especie de plantilla que define las
variables y métodos comunes para todos los objetos de cierto tipo.
Un diagrama de clases sirve para visualizar las relaciones
entre las clases que involucran el sistema, las cuales pueden ser asociativas,
de herencia, de uso y de contenido.
Un diagrama de clases esta compuesto por los siguientes
elementos:
-
Clase: atributos, métodos y visibilidad.
-
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Clase es la unidad básica que encapsula toda la información
de un Objeto (un objeto es una instancia de una clase). A través de ella podemos
modelar el entorno en estudio (un Libro, una Casa, una Cuenta Corriente, etc.).
En UML, una clase se representa por un rectángulo que posee
tres divisiones:
Representación de una clase en UML
Con el lenguaje de modelado UML podemos representar
gráficamente todo un sistema orientado a objetos utilizando rectángulos, líneas
y otro tipo de símbolos gráficos. Según UML, la clase "Cuenta Bancaria" podría
representarse gráficamente de la siguiente forma:
que indicaría que el nombre de la clase "Cuenta Bancaria", cuenta con los
atributos "tipo", "titular" y "saldo", y los métodos "depositar" y "extraer".
Los sistemas orientados a objetos permiten definir clases en
términos de otras clases. Por ejemplo novela y ensayo son diferentes tipos de
libros. En la terminología orientada a objetos "Novela" y "Ensayo" son subclases
de la clase "Libro". De forma similar Libro es la superclase de "Ensayo". De
esta forma se pueden establecer jerarquías de clases donde cada subclase hereda
los atributos de la clase a la que pertenece. La relación de herencia se
representa en UML mediante una flecha:
Pero las relaciones entre clases pueden ser de diferentes
tipos:
agregación:
asociación:
dependencia o instanciación (uso)
 , etc.
(Para ampliar y
profundizar este metamodelo, ir a Lenguaje UML
Hemos destacado aquí lo modelos principales, aunque existen otros muchos modelos
y metodologías: SOHDM (Metodología de Diseño Hipermedia Orientada a Objetos y
basada en Escenarios), WSDM (Método de Diseño de Sitios Web), WAE (Extensión de
Aplicación Web para UML), etc.
Bibliografía:
 AFRATI, F.,
KOUTRAS, L. "A Hypertext Model Supporing Query Mechanisms".
Proceeding European Conference on Hypertext Technology. Noviembre 1990. [Volver]
 AMBLER,
Scott. Home Page.
http://www.ambysoft.com/scottAmbler.html
BALASUBRAMANIAN, V. "State of the Art Review of Hypermedia:
Issues and Applications", 1995.
 BIANCHINI,
Adelaide. Modelo
referencial de hipermedio, basado en teoría de grafos para minimizar
el problema
de la desorientación del usuario.
http://www.ldc.usb.ve/~abianc/publicaciones.html
[Volver]
BLAT,
Josep. Hypermedia/Multimedia Systems (2004). Introduction: systems,
applications and models.
http://www.iua.upf.es/~jblat/material/doctorat/introduction.html
CAMPBELL, B., GOODMAN, J.
"HAM: A general purpose hypertext abstract machine". CACM, Vol. 31, Nº
7, July 1988. [Volver]
CONKLIN, Jeff. "Hypertext: An Introduction and Survey".
IEEE Computer, September 1987.
http://cs.aue.aau.dk/~kirstin/f7s2005/pdf/conklin.pdf
DE
BRA.
The Architecture of Hypertext
Systems. Eindhoven University of
Technology. http://wwwis.win.tue.nl/
CARIDAD,
Mercedes
y MOSCOSO, Purificación. Los sistemas de hipertexto e hipermedios.
Fundación Germán Sánchez Ruipérez, 1991.
CASANOVA, M., TUCHERMAN, L. et al. "The nested context model for
hyperdocuments". Proceedings ACM Conference on
Hypertext and Hypermedia - Hypertext'91. ACM Press, New York., 1991.
DONDO, Agustín. Programación orientada a objetos. Programación en
castellano.
http://programacion.com/articulo/dondo_poo/
Especificaciones UML.
http://www.popkin.com
MARTÍNEZ
SÁNCHEZ, José Manuel. HILERA GONZÁLEZ, José Ramón. "Modelado de
documentación multimedia e hipermedia" Cuadernos de Documentación
Multimedia, núm. 6-7, 1997-1998.
http://www.ucm.es/info/multidoc/multidoc/revista/cuad6-7/artmulti.htm
MUKHERJEA, S., FOLEY, J. "Visualizing the World Wide Web with a Navigational View
Builder". Proceedings Third International Conference on the World Wide Web
- WWW 1995. http://www.igd.fhg.de/www/www95/proceedings/papers/44/mukh/mukh.html
NAVARRETE
TERRASA, Toni. Modelos Hipermedia. Verano del 2000. http://www.iua.upf.es/~berenguer/cursos/interact/treballs/navarrete/modelos.pdf
[Volver]
NIELSEN, J.
Hypertext and Hypermedia. Oxford: Oxford Academic Press, 1990. [Volver]
OMG (Object
Management Group).
http://www.omg.org/
PARUNAK,
H. "Don't link me in: set based hypermedia for taxonomic reasoning".
Proceedings 3th ACM Conference on Hypertext and Hypermedia - Hypertext'91. ACM
Press, New York, 1991.
ROVIRA,
Cristòfol. La orientación a objetos en el diseño de hipertextos para
la enseñanza-aprendizaje.
http://www.ucm.es/info/multidoc/multidoc/revista/num8/rovira.html
SHNEIDERMAN, B.
Designing the user interface: Strategies for effective Human-Computer
Interaction. 3th ed. Massachusetts: Addison-Wesley, 1998.
TOMPA, F.
“A Data Model for Flexible Hypertext Database Systems”. ACMTOIS Vol 7.
Nº 1, January 1989. [Volver]
UML Resource Center. Popkin Software.
http://www.popkin.com/customers/customer_service_center/enterprise_architecture_resource_center/uml.htm
Unificied Modeling Language Resource Center (UML).
Popkin Software.
http://www.popkin.com/customers/customer_service_center/enterprise_architecture_resource_center/uml.htm
Universidad de Murcia.
Departamento de Información y Documentación. Hipertexto y World Wide Web:
Representación de información en entornos navegacionales.
http://www.um.es/gtiweb/fjmm/sarisite/2002-Trans-T1/SARI-trans-T1-p1.PPT
Van DAM, Andries. Hypertext
'87 keynote address. Communications of the ACM, 31, July 1988, 887-895.
[Volver]
De VOCHT, J.
"Experiments for the
Characterization of Hypertext Structures". Master's Thesis, Eindhoven
University of Technology. April 1994. http://wwwis.win.tue.nl/~debra/joep
-
Modelo Dexter
Modelo HAM
Modelo Trellis
Modelo Formal
Modelo Tower
Modelo Amsterdam
Modelo HDM
Modelo RMM
Modelo OOHDM
Lenguaje UML
| 
