UNIDAD 6
MODELOS PARA EL DISEÑO DE HIPERDOCUMENTOS
La producción de métodos o modelos para el diseño de hipertextos ha sido relativamente prolífica en el periodo comprendido entre finales de la década de los ochenta y la primera mitad de los noventa. A partir de la segunda mitad de los noventa se produjo un cambio de tendencia provocada por el rotundo éxito del servicio World Wide Web de Internet. Este nuevo medio generó un uso masivo del hipertexto a pesar que su objetivo principal no era el hipertexto en sí, sino el acceso a la información remota por medio de las redes telemáticas mundiales. La presión de millones de usuarios ha convertido a la tecnología Web en un estándar "de facto" para la creación de hipertextos.
Componentes de un Hiperdocumento:
Un hiperdocumento se puede definir, de manera formal, como un grafo G(N, E), donde N representa el conjunto de nodos de información y E representa el conjunto de enlaces (Fig. 1). Un nodo pueden caracterizarse de dos maneras: como una unidad de información o como un ítem de información.
Una unidad de información describe o hace referencia a un objeto del dominio de la aplicación; puede estar constituida por un conjunto de ítems de información multimedia y por un conjunto de botones, cada uno de éstos asociados con un enlace. Los ítems de información multimedia pueden ser: texto, sonido, gráficas, imágenes, un programa ejecutable o un video clip.
Un enlace puede conectar una unidad de información origen con una unidad de información destino o con un ítem de información.
El ámbito científico relacionado con el diseño y desarrollo de hipertextos no es homogéneo. En algunos casos se trata de metodologías completas que incluyen les tras fases del ciclo clásico de la ingeniería del software (análisis, diseño e implantación) como la RMM (Isakowitz, 1995); en otras ocasiones se trata solo de modelos abstractos para representar la estructura del hipertexto HDM (Garzotto, 1993); hay propuestas centradas en el diseño de las aplicaciones informáticas para crear y gestionar el hipertexto que incluyen también el diseño del procesamiento de la información (Stotts, 1989; Tomba 1989; Lange 1990); en cambio otros trabajos están centrados exclusivamente en el diseño de la estructura estática de la información (Schwabe, 1995; Isakowitz, 1995)
A pesar de estas diferencias, todos los autores proponen en la fase de diseño distintas perspectivas para observar y después representar un modelo del hipertexto. Es muy distinto centrar la atención en las características de la base de datos que almacena la información del hipertexto que observar la estructura de enlaces que el usuario utilizará para navegar por un determinado conjunto de nodos. Cada perspectiva permite realizar un modelo formal para representar aspectos complementarios del hipertexto. Todas estas representaciones se integran por medio de zonas fronterizas de encaje.
El problema está en que cada autor delimita perspectivas, fronteras y formas de encajar distintas. A menudo estas perspectivas se identifican como "niveles" o "capas" formando en su conjunto una "arquitectura del hipertexto". Algunos autores ordenan las capas de concreto a abstracto. Parten de los aspectos más físicos relacionados con la implementación, van subiendo hacia perspectivas más lógicas, como por ejemplo la estructura de navegación, para finalizar con la interfície de usuario o capa de presentación (Isakowitz, 1995); en otras ocasiones el contenido del hipertexto también forma una capa convenientemente relacionada con las otras perspectivas abstractas (Halasz, 1994).
Hay modelos formales del hipertexto que no tienen el objetivo de facilitar el diseño sino de permitir la comunicación y el intercambio de información entre distintos sistemas de gestión de hipertextos (Lange, 1990; Campbell, 1988). Este tipo de trabajos sirven de referentes para posteriormente crear metodologias para el diseño.
Ejemplo
La arquitectura del hipertexto que hemos utilizado para MEDHEA está formada por dos capas, una lógica y otra física. En la capa lógica se unifican todas las perspectivas abstractas y un solo modelo representa de manera integrada los siguientes aspectos:
- La estructura de navegación
- La estructura de relaciones semánticas del contenido
- Las características generales de la interfície de usuario
- La planificación didáctica del proceso de enseñanza - aprendizaje que genera el hipertexto
En la capa física quedarían representados los aspectos relacionados con la implementación informática y el procesamiento de la información. Finalmente, hay que considerar una zona fronteriza entre la capa lógica y la física para indicar la manera de implementar el modelo lógico en función de las características de la tecnología elegida para crear el hipertexto.
Según el ciclo de vida de la ingeniería del software, la capa lógica formaría parte del diseño lógico, la zona fronteriza correspondería al diseño tecnológico y la capa física a la implementación.
MEDHEA es una metodología para el diseño de hiperdocumentos. Incluye el diseño lógico de la estructura de la navegación, el diseño didáctico y la fragmentación de la información en nodos, pero no abarca el diseño de los procesos informáticos que harán posible que el hipertexto funcione. Los modelos lógicos creados con MEDHEA podrán ser implementados utilizando un sistema de gestión de hipertextos (Hypercard, Guide…) o mediante la tecnología Web con el formato HTML. La fase de diseño tecnológico de MEDHEA adapta el modelo lógico a las características de la tecnología de implementación elegida.
6.1 Modelos abstractos para diseñar hiperdocumentos
Las herramientas de representación gráfica utilizadas en la fase de diseño lógico por la ingeniería del software para modelar los sistemas de información permiten también realizar un modelo abstracto de un hipertexto.
"Un modelo es una abstracción de algo, cuyo objetivo es comprenderlo antes de construirlo. Dado que los modelos omiten los detalles no esenciales, es más sencillo manipularlos que manipular la entidad original. La abstracción es una capacidad humana fundamental que nos permite enfrentarnos a la complejidad. Los ingenieros, artistas y artesanos han estado construyendo modelos durante miles de años para probar los diseños antes de ejecutarlos. El desarrollo de sistemas hardware y software no es una excepción. Para construir sistemas complejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfacen los requisitos del sistema y añadir, gradualmente, detalles para trasformar los modelos en una implementación." (Rumbaugh et al. 1996: 37)
La técnica del modelado orientado a objetos se utiliza de una forma generalizada por la Ingeniería del Software para el diseño de aplicaciones informáticas. La finalidad del diseño orientado a objetos es realizar un modelo del sistema de información considerando que su estructura interna está formada por un conjunto de objetos que interactúan entre sí. Cada objeto tiene unas propiedades y un comportamiento que representan respectivamente la estructura de la información y su procesamiento.
Todos los objetos con las mismas características forman una "clase" y cada objeto concreto perteneciente a una clase se llama "instancia de clase" o simplemente "objeto". Podríamos considerar que la clase es la plantilla del objeto y la instancia es un objeto operativo con unos valores determinados.
La representación gráfica por medio del modelo orientado a objetos permite depurar el diseño antes de iniciar la creación del hiperdocumento expresando sobre un esquema los siguientes elementos:
- Diseño de la navegación
- La amplitud y profundidad de las jerarquías de nodos
- El exceso de enlaces asociativos
- La ausencia de enlaces asociativos
- El tipo de nodos utilizado en el hiperdocumento
- Los nodos que el usuario podrá modificar
- Los nodos que el usuario podrá añadir
- Los conjuntos de nodos que forman una unidad de navegación
- Diseño didáctico
- El desglose de objetivos didácticos generales en específicos
- La integración de objetivos didácticos, contenidos, ejercicios de autoevaluación y evaluación final
- La temporalización de las actividades a realizar en el proceso de aprendizaje
El modelo orientado a objetos combina tres puntos de vista para representar todos los aspectos de un sistema de información: el modelo de objetos para la representación estática de la estructura de la información; el modelo dinámico para los aspectos temporales del comportamiento del sistema y finalmente, el modelo funcional para representar los procesos que transforman la información del sistema (Rumbaugh, 1996).
En la adaptación de esta herramienta al diseño de hiperdocumentos solo aplicamos el modelo de objetos. No es necesario entrar en los aspectos dinámicos y del funcionamiento del hipertexto porqué ya están resueltos con un SGH o utilizando tecnología Web.
Cada objeto tiene unas "propiedades" que indican sus características y unas operaciones o "métodos" para representar los procesos en los que el objeto está involucrado. Todos los objetos con las mismas propiedades y métodos pertenecen a una determinada "clase" de objetos y cada uno de los ejemplares de una clase se denomina "instancia de la clase".
Las conexiones físicas o conceptuales entre objetos se llaman "enlaces" y un grupo de enlaces del mismo tipo y con la misma semántica se denomina "asociación". De la misma forma que una clase representa un tipo general de objetos, una asociación representa un tipo general de enlaces.
No forzamos la orientación a objetos si consideramos que cada nodo de un hiperdocumento es un objeto o instancia de objeto que pertenece a una "clase de nodos" y que cada enlace hipertextual es un "enlace" en el sentido de la orientación a objetos que pertenece a un tipo general de enlaces o "asociación".
Aunque desde el punto de vista de la sintaxis haya una adaptación directa de la orientación a objetos al diseño de hiperdocumentos, hay diferencias semánticas importantes sobre aquello que representa un "objeto" y un "enlace" cuando el modelado se aplica a la creación de aplicaciones informáticas o a la creación de hiperdocumentos.
En el primer caso, los objetos representan los datos internos del programa asociados a los procesos (métodos) en los que intervienen. En cambio, los objetos en un hiperdocumento representan los nodos, la información externa que ve el usuario, sin considerar ningún tipo de proceso.
Por otro lado, los enlaces del modelo de una aplicación informática representan las relaciones
entre los datos internos. El conjunto de todos los enlaces muestra la estructura interna del almacenaje de la información que utiliza la aplicación. Los procesos de transformación de esta información determinarán que relaciones se establecerán entre los datos para conseguir mantener su consistencia y facilitar su actualización.
En cambio, en un hiperdocumento los enlaces de la orientación a objetos representan los enlaces hipertextuales unidireccionales y por tanto modelan los itinerarios de consulta que tendrán los usuarios para saltar de un nodo a otro. La creación de un enlace está determinada por el significado de la información que contiene cada nodo y el conjunto de todos los enlaces muestra la estructura de navegación del hiperdocumento. Estas diferencias en al semántica de la representación no impiden utilizar toda la potencia del modelado orientado a objetos en el diseño de hiperdocumentos aunque sea necesario realizar algunas adaptaciones.
En función del número de instancias implicadas hay tres tipos básicos de asociaciones. La línea acabada con un punto negro indica una relación de una instancia de la primera clase con "cero o más" instancias de la segunda; la línea acabada con un círculo blanco indica que la relación será de uno con "cero o uno" y la línea sin círculos indica una relación de uno con uno.
En el diseño de hiperdocumentos cada asociación del tipo "de uno con uno" se traduce en un enlace hipertextual unidireccional entre un nodo del primer tipo hacia otro del segundo. Las asociaciones del tipo "de uno con n" se traducen en "n" enlaces hipertextuales unidireccionales entre "n" orígenes distintos, todos ellos situados en un nodo del primer tipo, y "n" nodos distintos pertenecientes al segundo tipo de nodos de la asociación. En la orientación a objetos existen dos formas especiales de asociaciones: la agregación y la herencia también llamada generalización. En el primer caso la relación entre objetos es del tipo "del todo a las partes" en la cual un objeto se relaciona con otros que son sus partes componentes. En la herencia se establece una relación entre una clase y otras que son versiones más refinadas de esta clase inicial y que constituyen sus subclases. En el diseño de hiperdocumentos la agregación y la herencia se utilizan con la misma notación y significado que en la orientación a objetos clásica.
La agregación resulta útil para representar a los menús que incorporan los nodos. Los menús forman una entidad constante que aparecen en multitud de nodos y por tanto pueden ser considerados como un objeto independiente. Todos los nodos que mantienen una relación de agregación con un determinado menú formaran una unidad de navegación. Con la herencia se pueden expresar las similitudes estructurales entre varias clases de nodos.
Finalmente hay que considerar una situación que se produce en el diseño de hiperdocumentos y que no está contemplada en el diseño orientado a objetos. Esta circunstancia que hemos llamado "enlace alternativo" se produce cuando un nodo enlaza de manera condicional con otro y en función de la instancia que quiera construirse se materializará o no el enlace.
Tabla 1: Adaptación del modelo orientado a objetos al diseño de hiperdocumentos
| ||
Modelo orientado a objetos para una aplicación informática
|
Modelo orientado a objetos para un hiperdocumento
| |
Modelos
necesarios |
Modelo de objetos
Modelo dinámico Modelo funcional |
Modelo de objetos
- - |
Conceptos
básicos |
Objeto (instancia de objeto)
Atributo de objeto Método (operación) Clase Enlace (relación) Asociación Agregación Herencia - Herencia de clases Agregación de clases Polimorfismo |
Nodo, menú
Características del nodo - Tipo de nodo Enlace hipertextual unidireccional Tipo de enlace hipertextual Agregación entre nodos Herencia entre nodos Enlace alternativo Herencia de tipo de nodos Agregación de nodos - |
En la notación gráfica para el diseño de hiperdocumentos hemos añadido dos símbolos para adaptar el modelado orientado a objetos OMT (Rumbaugh, 1996): las líneas que representan los enlaces incorporan una flecha para indicar su dirección y un círculo negro en la línea del enlace para indicar la presencia de un enlace alternativo.
6.1.1 Modelos dentro del ciclo de desarrollo del sistema
El analista debería aplicar un enfoque sistemático en el análisis y el diseño de los sistemas de información. El ciclo de desarrollo de los sistemas o ciclo de vida de los sistemas (SDLC: Systems Devetopment Life Cycle) es un enfoque por etapas de análisis y de diseño, que postula que el desarrollo de los sistemas mejora cuando existe un ciclo específico de actividades del analista y de los usuarios.
En general, los analistas no están de acuerdo respecto al número exacto de etapas que conforman el ciclo de desarrollo de los sistemas; sin embargo, se reconoce la importancia de su enfoque sistemático. Se dividirá el ciclo de vida en siete etapas, que aunque se presentan de manera discreta, nunca se llevan a cabo como un elemento Independiente. En lugar de ello. se realizan al mismo tiempo diversas actividades, y éstas llegan a repetirse. Por ello es de mayor utilidad suponer que el ciclo de desarrollo de los sistemas transcurre en etapas (con actividades en acción que luego cesan poco a poco) y no como elementos separados.
1) Identificación de problemas, oportunidades y objetivos.
En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el éxito del resto del proyecto, pues nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado.
La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organización hará notar los problemas. Muchas veces esto ya fue realizado previamente: y por ello es que se llega a invitar al analista.
Las oportunidades son acuellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de información computarizados. Al aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estándar industrial.
La identificación de objetivos también es un componente importante de la primera fase. En un comienzo, el analista deberá descubrir lo que la empresa intenta realizar, y luego estará en posibilidad de determinar si el uso de los sistemas de información apoyaría a la empresa para alcanzar sus metas, el encaminarla a problemas u oportunidades específicas.
2) Determinación de los requerimientos de información.
La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de los usuarios particularmente involucrados. Para identificar los requerimientos de información dentro de ¡a empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios: la observación de la conducta de quien toma las decisiones, así como de su ambiente: y también el desarrollo de prototipos.
En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas. Puede ver, cómo varios de los métodos para establecer las necesidades de información, lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo de los sistemas. El analista es el especialista que emprende esta clase de estudios.
3) Análisis de las necesidades del sistema.
La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema. Una vez más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen el uso de los diagramas de flujo de datos (DFD) que cuentan con una técnica estructurada para representar en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus especificaciones, si son alfanuméricos, descripción, clave primaria, entre otros.
Durante esta fase. el analista de sistemas también analiza las decisiones estructuradas por realizar, que son decisiones donde las condiciones, condiciones alternativas, acciones y reglas de acción podrán determinarse. Existen tres métodos para el análisis de las decisiones estructuradas: el lenguaje estructurado (en nuestro caso el español), las tablas de decisión y los árboles de decisión.
No todas las decisiones en las empresas se encuentran estructuradas; no obstante, es importante que las comprenda el analista de sistemas.
Las decisiones semiestructuradas (decisiones que se toman bajo nesgo) con frecuencia se apoyan en los Sistemas de Toma de Decisiones. Cuando analiza las decisiones semiestructuradas el analista las examina de acuerdo con el grado de complejidad del problema y con el número de criterios considerados al llevar a cabo las decisiones.
El análisis de decisiones de criterio múltiple (aquellas decisiones donde numerosos factores tienen que equilibrarse) también es parte de esta etapa. Se disponen de muchas técnicas para el análisis de decisiones de criterio múltiple; incluyendo entre otras, e! proceso de intercambio y la aplicación de métodos de ponderado.
A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta del sistema que resume todo lo que ha encontrado, presenta un análisis costo / beneficio de las alternativas y plantea las recomendaciones (si es que existen) de lo que deberá realizarse. Si la dirección acepta alguna de las recomendaciones, el analista procederá de acuerdo con ella.
4) Diseño del sistema recomendado.
En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con anterioridad y elabora el diseño lógico del sistema de información. El analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. Ei analista también diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de pantallas.
Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario. La interfaz conecta al usuario con el sistema, y evidentemente, es de suma importancia. Serían ejemplos de interfaces para el usuario: el uso del teclado para introducir preguntas o respuestas, el uso de menús en la pantalla, con las opciones que tiene el usuario, el uso de dispositivos como el ratón (mouse) y muchos otros.
La etapa del diseño también incluye e! diseño de los archivos o la base de datos que almacenará aquellos datos requeridos por quien toma las decisiones en la organización. Una base de datos bien organizada es fundamental para cualquier sistema de información. En esta etapa, el analista diseña la salida (en pantalla o impresa) hacia el usuario, de acuerdo con sus necesidades de información.
5) Desarrollo y documentación del software
En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación del software se tienen: el método HIPO, los diagramas de flujo, los diagramas Nassi-Schneiderman, los diagramas Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite al programador los requerimientos de programación.
Durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del software, incluyendo los manuales de procedimientos. La documentación le dirá al usuario como operar el software, y así también, qué hacer en caso de presentarse algún problema.
6) Pruebas v mantenimiento del sistema.
El sistema de información debe probarse antes de utilizarlo. El costo es menor si se detectan los problemas antes de la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista de sistemas. En un principio, se hace una serie de pruebas, con datos tipo, para identificar las posibles fallas del sistema: más adelante, se utilizarán los datos reales.
El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después, esta función se realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina del programador, que para las empresas llegan a implicar importantes sumas de dinero. Sin embargo, el costo del mantenimiento disminuye de manera importante cuando el analista aplica procedimientos sistemáticos en el desarrollo de los sistemas.
7) Implantación y evaluación de sistema.
En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de información. Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales, la supervisión del adiestramiento es una responsabilidad del analista de sistemas. Más aún, el analista necesita planear la suave transición que trae consigo un cambio de sistemas.
Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los sistemas; realmente, la evaluación toma parte en cada una de las etapas. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado.
6.2 Retrospectiva de los modelos para hipermedia
No podemos olvidar que muchos de los estudios y aplicaciones de los diseños de hipertexto que se sustentan sobre la Web actual, tienen su base en la formulación y el diseño de modelos creados anteriormente para correr fuera de ella y funcionar como sistemas independientes y aislados de hipertexto. Los sistemas pioneros en la gestión de hipertextos ya forman parte indisoluble de la historia del hipertexto y, los llamados sistemas pre-web, esto es, los desarrollados antes de que se generalizara la World Wide Web forman parte de la propia historia de la WWW ya que su tecnología y puesta en práctica fue fundamental para el desarrollo de ésta.
He aquí un pequeño recorrido retrospectivo por los principales sistemas de gestión de hipertextos independientes anteriores a la Web, son los denominados sistemas pre-web.
En 1985, Peter Brown, investigador de la Universidad de Maryland, desarrolla Guide, el primer sistema de creación de hipertexto paraordenadores personales (inicialmente, para los Macintosh de Apple, aunque en 1987 se comercializó la versión para PC). Guide disponía de unainterfaz gráfica muy simple e intuitiva.
En 1986 nacen otros sistemas que ofrecen una presentación gráfica de la estructura para facilitar la interacción y que pueden procesar imágenes y animaciones: NoteCards de Xerox PARC, Knowledge Management System (KMS) e Intermedia. NoteCards, desarrollado por Frank Halasz, es el primer programa que utiliza metáforas en el ámbito hipertextual. Intermedia (1987-92), de Andries Van Dam, un sistema orientado a la enseñanza de biología y literatura inglesa, y a la construcción de ficción hipertextual.
En 1987, aparece HyperCard que, sin ser una herramienta de creación de hipertextos, se convirtió en un estándar muy popular gracias a la política de Apple, que lo incluía en el paquete de software de los Macintosh. Desde entonces hasta la actualidad, han aparecido un gran número de programas orientados a crear y estructurar información hipertextual para la mayoría de las plataformas informáticas.
En 1989, Autodesk Inc. comercializa el sistema Xanadú diseñado por Ted Nelson.
En los años 90, nacen los multimedia interactivos. Se celebra la Primera Conferencia Europea sobre Tecnología Hipertextual (ECHT), y comienzan a consolidarse las primeras aplicaciones informáticas orientadas a la integración de medios en un mismo soporte y a interconectar estos elementos posibilitando al usuario el acceso no lineal y selectivo a la información multimediática. Los sistemas multimedia interactivos, se popularizan sobre todo a través de la incorporación masiva de los CD-ROM a los ordenadores personales y a que muchas empresas editoriales empiezan a crear programas interactivos multimedia: enciclopedias, juegos, etc.
Veamos con más detenimiento las características y desarrollo de cada uno de los sistemas pre-web.
El e-laboratorio de la Universidad de Virginia llevó a cabo un análisis muy detallado de todos los sistemas y softwares de hipertexto que existían allá por 1993. Es interesante consultar estas páginas para tener una foto retrospectiva de cómo estaban los distintos sistemas de hipertexto en un particular punto de su desarrollo y, aunque muchos de ellos ya han desaparecido o han evolucionado enormemente, es increíble comprobar, las enormes capacidades y posibilidades que ofrecían ya por aquellas fechas.
Como era imposible evaluar todos los sistemas de hipertexto existentes, para realizar este estudio se tomaron muestras y ejemplos de sistemas de gestión hipertexto de cada uno de los paradigmas estructurales que existían teniendo en cuenta esta clasificación:
Sistemas Basados en Tarjetas (Card) prevén un tamaño fijo y nodos a pantalla completa. No está disponible una barra de desplazamiento, sino que todo el texto del nodo debe caber en la pantalla. Este tipo de software se basa en un tablero y un puntero o la metáfora de exhibición de diapositivas, y comúnmente se usa para crear demostraciones de software, presentacionesinteractivas, etc. La metáfora del tablero es demasiado restrictiva para la mayor parte de los objetivos y esto obliga a los autores a manejar los nodos de una manera poco natural puesto que los trozos de texto son muy pequeños. En este tipo de sistemas se encuentran: HyperShell, HyperTies, HyperWriter! y Orpheus
Los sistemas como HyperCard: se basan en el paradigma de las tarjetas, pero agregan elementos de interfaz muy ricos y un lenguaje de scripts. El ejemplo más claro de este tipo fueHyperCard que aglutinó a cientos de miles de programadores y usuarios de ordenador, pero existen otros ejemplos de software que utilizan este sistema como: HyperPad, LinkWay, PLUS, yToolBook.
Como el desarrollo de estos sistemas fue continuo, existieron pocos paquetes que se mantuvieran estrictamente dentro del paradigma de Card. Por ejemplo, HyperCard 2.1, Plus 2.5, e HyperWriter! 3.0 permiten ventanas desplazables y el texto en un nodo es más limitado que el que puede mostrarse sobre una pantalla. Sin embargo, la configuración de estos paquetes todavía favorece la metáfora de las tarjetas y no suministran un ambiente rico para el hipertexto. Una excepción es KMS, que toma el paradigma de la tarjeta en su límite lógico.
Sistemas basados en documentos: se enfocan hacia la corrección de texto y el formato de documentos. A menudo son extensiones de procesadores de textos y no son óptimos para laescritura no lineal. Ejemplos de hipertexto de este tipo son FrameMaker y Guide.
Sistemas basados en ventanas: suministran una interfaz muy rica gracias a las acciones que permiten el uso de ventanas múltiples y barras de desplazamiento. Esto permite que los lectores puedan comparar dos páginas de texto, escribir anotaciones viendo una segunda página, etc. Los ejemplos incluyen Dart, Folio VIEWS, gIBIS, Intermedia, Knowledge Pro, NoteCards,SmarText, StorySpace, y Windows Help Compiler.
Algunos autores investigaron los paradigmas estructurales desde el punto de vista de la eficacia de un lector al completar una tarea dada y llegaron a la conclusión de que un documento en una sola ventana desplegable era una interfaz más eficiente que una vista con marco o que la utilización de una ventana dual para mostrar las páginas. Cuando se agregaba un mapa para mostrar la información estructural, la interfaz era aún más eficiente.
El software disponible comercialmente solía correr para uno de los 3 entornos existentes, aunque algunos paquetes servían para varios de ellos porque ofrecían compatibilidad entre plataformas.
Entornos y programas:
DOS: Dart, Folio VIEWS, HyperPad, HyperShell, HyperTies, HyperWriter!, Knowledge Pro, LinkWay y Orpheus
Windows: FrameMaker, Guide, Knowledge Pro, PLUS, SmarText, ToolBook y Windows Help Compiler
Apple: FrameMaker, Guide HyperCard, PLUS y Storyspace
Workstation: IBIS, InterMedia, KMS, Memex, NoteCards y Xanadu
La siguiente tabla muestra los principales sistemas de gestión de hipertextos anteriores a la aparición de la World Wide Web, y que analizaremos detenidamente:
En 1985, Peter Brown, investigador de la Universidad de Maryland, desarrolla Guide, el primer sistema de creación de hipertexto paraordenadores personales (inicialmente, para los Macintosh de Apple, aunque en 1987 se comercializó la versión para PC). Guide disponía de unainterfaz gráfica muy simple e intuitiva.
En 1986 nacen otros sistemas que ofrecen una presentación gráfica de la estructura para facilitar la interacción y que pueden procesar imágenes y animaciones: NoteCards de Xerox PARC, Knowledge Management System (KMS) e Intermedia. NoteCards, desarrollado por Frank Halasz, es el primer programa que utiliza metáforas en el ámbito hipertextual. Intermedia (1987-92), de Andries Van Dam, un sistema orientado a la enseñanza de biología y literatura inglesa, y a la construcción de ficción hipertextual.
En 1987, aparece HyperCard que, sin ser una herramienta de creación de hipertextos, se convirtió en un estándar muy popular gracias a la política de Apple, que lo incluía en el paquete de software de los Macintosh. Desde entonces hasta la actualidad, han aparecido un gran número de programas orientados a crear y estructurar información hipertextual para la mayoría de las plataformas informáticas.
En 1989, Autodesk Inc. comercializa el sistema Xanadú diseñado por Ted Nelson.
En los años 90, nacen los multimedia interactivos. Se celebra la Primera Conferencia Europea sobre Tecnología Hipertextual (ECHT), y comienzan a consolidarse las primeras aplicaciones informáticas orientadas a la integración de medios en un mismo soporte y a interconectar estos elementos posibilitando al usuario el acceso no lineal y selectivo a la información multimediática. Los sistemas multimedia interactivos, se popularizan sobre todo a través de la incorporación masiva de los CD-ROM a los ordenadores personales y a que muchas empresas editoriales empiezan a crear programas interactivos multimedia: enciclopedias, juegos, etc.
Veamos con más detenimiento las características y desarrollo de cada uno de los sistemas pre-web.
El e-laboratorio de la Universidad de Virginia llevó a cabo un análisis muy detallado de todos los sistemas y softwares de hipertexto que existían allá por 1993. Es interesante consultar estas páginas para tener una foto retrospectiva de cómo estaban los distintos sistemas de hipertexto en un particular punto de su desarrollo y, aunque muchos de ellos ya han desaparecido o han evolucionado enormemente, es increíble comprobar, las enormes capacidades y posibilidades que ofrecían ya por aquellas fechas.
Como era imposible evaluar todos los sistemas de hipertexto existentes, para realizar este estudio se tomaron muestras y ejemplos de sistemas de gestión hipertexto de cada uno de los paradigmas estructurales que existían teniendo en cuenta esta clasificación:
Sistemas Basados en Tarjetas (Card) prevén un tamaño fijo y nodos a pantalla completa. No está disponible una barra de desplazamiento, sino que todo el texto del nodo debe caber en la pantalla. Este tipo de software se basa en un tablero y un puntero o la metáfora de exhibición de diapositivas, y comúnmente se usa para crear demostraciones de software, presentacionesinteractivas, etc. La metáfora del tablero es demasiado restrictiva para la mayor parte de los objetivos y esto obliga a los autores a manejar los nodos de una manera poco natural puesto que los trozos de texto son muy pequeños. En este tipo de sistemas se encuentran: HyperShell, HyperTies, HyperWriter! y Orpheus
Los sistemas como HyperCard: se basan en el paradigma de las tarjetas, pero agregan elementos de interfaz muy ricos y un lenguaje de scripts. El ejemplo más claro de este tipo fueHyperCard que aglutinó a cientos de miles de programadores y usuarios de ordenador, pero existen otros ejemplos de software que utilizan este sistema como: HyperPad, LinkWay, PLUS, yToolBook.
Como el desarrollo de estos sistemas fue continuo, existieron pocos paquetes que se mantuvieran estrictamente dentro del paradigma de Card. Por ejemplo, HyperCard 2.1, Plus 2.5, e HyperWriter! 3.0 permiten ventanas desplazables y el texto en un nodo es más limitado que el que puede mostrarse sobre una pantalla. Sin embargo, la configuración de estos paquetes todavía favorece la metáfora de las tarjetas y no suministran un ambiente rico para el hipertexto. Una excepción es KMS, que toma el paradigma de la tarjeta en su límite lógico.
Sistemas basados en documentos: se enfocan hacia la corrección de texto y el formato de documentos. A menudo son extensiones de procesadores de textos y no son óptimos para laescritura no lineal. Ejemplos de hipertexto de este tipo son FrameMaker y Guide.
Sistemas basados en ventanas: suministran una interfaz muy rica gracias a las acciones que permiten el uso de ventanas múltiples y barras de desplazamiento. Esto permite que los lectores puedan comparar dos páginas de texto, escribir anotaciones viendo una segunda página, etc. Los ejemplos incluyen Dart, Folio VIEWS, gIBIS, Intermedia, Knowledge Pro, NoteCards,SmarText, StorySpace, y Windows Help Compiler.
Algunos autores investigaron los paradigmas estructurales desde el punto de vista de la eficacia de un lector al completar una tarea dada y llegaron a la conclusión de que un documento en una sola ventana desplegable era una interfaz más eficiente que una vista con marco o que la utilización de una ventana dual para mostrar las páginas. Cuando se agregaba un mapa para mostrar la información estructural, la interfaz era aún más eficiente.
El software disponible comercialmente solía correr para uno de los 3 entornos existentes, aunque algunos paquetes servían para varios de ellos porque ofrecían compatibilidad entre plataformas.
Entornos y programas:
DOS: Dart, Folio VIEWS, HyperPad, HyperShell, HyperTies, HyperWriter!, Knowledge Pro, LinkWay y Orpheus
Windows: FrameMaker, Guide, Knowledge Pro, PLUS, SmarText, ToolBook y Windows Help Compiler
Apple: FrameMaker, Guide HyperCard, PLUS y Storyspace
Workstation: IBIS, InterMedia, KMS, Memex, NoteCards y Xanadu
La siguiente tabla muestra los principales sistemas de gestión de hipertextos anteriores a la aparición de la World Wide Web, y que analizaremos detenidamente:
6.2.1 Modelos basados en grafos
Modelos de hipertextos Según [DRAE, 1992], un modelo es la expresión de una realidad o sistema complejo mediante algún lenguaje formal o simbolismo gráfico que facilita su comprensión y el estudio de su comportamiento. Por su propia definición, un modelo debe cumplir con tres requisitos básicos: General, es decir, debe ser válido para cualquier aplicación del campo que formaliza. Abstracto, ya que con esto se puede separar las características particulares del objeto de estudio para extraer su esencia. Consistente, para lograr que cada elemento tenga una única definición, acorde con la función que se espera que represente y coherente con el resto de componentes del modelo. En la literatura se encuentra una amplia gama de descripciones de hipertextos, en su mayoría utilizan como submodelo de datos derivaciones y extensiones de grafos, modelos expresados en lenguaje formal y modelos basados en el paradigma orientado a objetos. Los más conocidos son: Modelo basado en hipergrafos, debido a [Tompa, 1989] Modelo basado en grafos para el desarrollo de NEPTUNE [Delisle et al, 1986] Modelo basado en redes de Petri, cuya implementación es el sistema Trellis [Stotts et al, 1989]. Modelo basado en "Contextos anidados", [Casanova et al, 1991] y los basados en Higrafos [Mattos et al, 1997]. Estos dos modelos se pueden describir como grafos dirigidos, sin embargo en cada caso sus autores prefirieron utilizar el formalismo propio de teoría de conjuntos. Modelo expresados en lenguaje formal, cuya implementación es el sistema Dexter [Halasz et al, 1994] y su derivado Amsterdam [Hardman et al, 1994]. Modelo orientado a objeto como es el caso de [Lange, 1990] donde define la clase principal Hyperbase, constituída en su nivel básico de una estructura de grafo dirigido.
6.2.2 Modelos basados en redes de Petri
Las redes de Petri son una herramienta gráfica y matemática de modelación que se puede aplicar en muchos sistemas. Particularmente son ideales para describir y estudiar sistemas que procesan información y con características concurrentes, asíncronas, distribuidas, paralelas, no determinísticas y/o estocásticas. El objetivo de este capítulo es presentar los conceptos básicos de las redes de Petri. A partir de las definiciones formales de redes de Petri, se presentan aspectos de modelado, comportamiento y técnicas de análisis.
Las redes de Petri se prestan para la modelación si se conoce la estructura causa-evento2.3 de un sistema y se utiliza para definir el modelo. Los lugares representan causas o condiciones, y las transiciones eventos.
En sistemas donde se conoce la estructura causa-evento, las redes de Petri resultan ser una excelente herramienta para establecer un modelo de dicho sistema. En esta representación gráfica, los nodos son lugares que representan causas o condiciones, y las transiciones eventos. Las redes de Petri modelan sistemas dinámicos discretos. En este orden de ideas, los eventos se generan, en una parte local del estado actual del sistema, como variables discretas.
Una red de Petri es una estructura matemática, que permite una representación gráfica, en donde se incluyen los elementos: lugares transiciones, arcos y tokens, en un diagrama que tiene una sintaxis.
Los lugares son los elementos pasivos de la red de Petri y, junto con los tokens, se utilizan para modelar los estados del sistema.
Las transiciones son los elementos activos de la red de Petri, y representan las acciones de un sistema. Estas acciones originan cambios en el estado de la red.
El conjunto de lugares, transiciones y arcos son finitos y estáticos. Lo que indica que el sistema no puede tener mas causas y eventos que los que originalmente tiene representados en el modelo.
El conjunto de tokens y marcas pueden cambiar durante la ejecución de la red, describiendo las características dinámicas del sistema modelado.
La propiedad de valor de peso a los arcos, hace posible que se especifique el número de tokens que consume la transición de los lugares de entrada y el conjunto de tokens que produce en la salida. Las redes de Petri de capacidad finita y peso en los arcos se les llama sistemas de lugar/transición.
Las clases originales de redes de Petri, y los sistemas de lugar/transición son muy conocidos por su uso en modelos de un alto grado de abstracción que tienen que analizarse de manera formal. Pero si el modelo debe respetar más detalles del sistema, o si se debe respetar el tiempo en el modelo, entonces se deben desarrollar más clases de redes de Petri que consideran los aspectos deseados del modelo. Así, surgen las redes de Petri coloreadas, estocásticas, y orientadas a objetos, por mencionar algunas, que en general forman el grupo de redes de Petri extendidas.
Ejemplos de modelación con redes de Petri son el flujo de información y los protocolos de comunicación. Se muestran ejemplos de estos modelos.
6.2.3 Modelos expresados en lenguaje formal
Un sistema formal es un tipo de sistema lógico-deductivo constituido por un lenguaje formal, una gramática formal que restringe cuales son las expresiones correctamente formadas de dicho lenguaje y las reglas de inferencia y un conjunto de axiomas que permite encontrar las proposiciones derivables de dichos axiomas. Los sistemas formales también han encontrado aplicación dentro de la informática, la teoría de la información, y la estadística, para proporcionar una definición rigurosa del concepto de demostración. La noción de sistema formal corresponde a una formalización rigurosa y completa del concepto de sistema axiomático, los cuales pueden ser expresados en lenguaje formal o en lenguaje natural formalizado.
Llamamos formalización al acto de crear un sistema formal, con la que pretendemos capturar y abstraer la esencia de determinadas características del mundo real, en un modelo conceptual expresado en un determinado lenguaje formal.
En la Teoría de la demostración, las demostraciones formales pueden expresarse en el lenguaje de los sistemas formales, consistentes en axiomas y reglas de inferencia. Los teoremas pueden ser obtenidos por medio de demostraciones formales. Este punto de vista de las matemáticas ha sido denominado formalista; aunque en muchas ocasiones este término conlleva una acepción peyorativa. En ese sentido David Hilbert creó la disciplina denominada metamatemática dedicada al estudio de los sistemas formales, entendiendo que el lenguaje utilizado para ello, denominadometalenguaje era distinto del lenguaje del sistema formal que se pretendía estudiar. El lenguaje formal que se estudia, en este caso se llama también, en ocasiones, lenguaje objeto.
Un sistema así es la reducción de un lenguaje formalizado a meros símbolos, lenguaje formalizado y simbolizado sin contenido material alguno; un lenguaje reducido a mera forma que se expresa mediante fórmulas que reflejan las relaciones sintácticas entre los símbolos y las reglas de formación y transformación que permiten construir las fórmulas del sistema y pasar de una fórmula a otra.1
El objetivo de un sistema formal es señalar como válidas determinadas cadenas. Estas cadenas válidas se denominan teoremas. Para obtener los teoremas se emplean las reglas de producción que convierten una cadena en otra. Hay ciertos teoremas iniciales que no se obtienen de ninguna regla, éstos son los axiomas que se suponen válidos por definición y se convierten en el germen de producción de teoremas.
6.2.4 Utilización de notaciones gráficas.
Notaciones gráficas
Redes de Tareas: En ellas se representan las actividades que deben ejecutarse en paralelo y las que deben
llevarse a cabo en secuencia debido a una dependencia respecto a la actividad o actividades anteriores.
- Los nodos rectangulares representan las tareas.
- Los nodos redondeados representan los hitos
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.
La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso, coherentes y consistentes, promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
6.4 Modelo genérico para la hipermedia: Labyrinth
El modelo Labyrinth representa a una aplicación hipermedia a través de un Hiperdocumento Básico, donde se especifican cierto número de elementos para definir la estructura y el comportamiento de una aplicación. Además cada usuario o grupo de usuarios puede tener un Hiperdocumento Personalizado, donde los usuarios pueden adaptar componentes del Hiperdocumento Básico para sus propios requisitos, o crear uno nuevo.
6.4.1 Elementos del modelo
® Usuarios
® Nodos
® Contenidos
® Anclas
® Enlaces
® Atributos
® Eventos
® Localización
6.4.2 Notación del modelo de Labyrinth
Por tanto, un Hiperdocumento (HD) se define como la unión de un Hiperdocumento Básico (HDB) y una serie de Hiperdocumentos Personalizados (HDP), cada uno de los cuales pertenece a un grupo de usuarios. Es decir,
HD = HDB ∪ HDP
Donde,
HDB = (U, N, C, A, L, B, E, lo, al, el, ac)
Donde,
- U, es el conjunto de usuarios del hiperdocumento
- N, es el conjunto de nodos del hiperdocumento
- C, es el conjunto de contenidos del hiperdocumento
- A, es el conjunto de anclas del hiperdocumento
- L, es el conjunto de enlaces del hiperdocumento
- B, es el conjunto de atributos del hiperdocumento
- E, es el conjunto de eventos del hiperdocumento
- lo, es una función que determina la localización de un contenido en un nodo, es decir,
lo: ∀ C I ∈ C, ∀ N j ∈ N | i = 0,..., n, n ∈ N, j = 0,..., m, m ∈ N, lo(Ci, Nj) = { Posicióni, Tiempoi}
Donde,
Posicióni es la posición del contenido en el nodo
Tiempoi = {Comienzo i, Duración i} indica el momento el que el contenido se coloca
en el nodo, y el intervalo de permanencia en él.
- al, es una función que asigna valores a la lista de atributos de un elemento, es decir,
al: ∀ x ∈ (U ∪ N ∪ C ∪ L), al(x) = {NombreAtributoi, Valori}, i = 0,..., n, n ∈ N,
NombreAtributoi ∈ Bi
- el, es una función asigna eventos a un elemento, es decir,
el: ∀ x ∈ (N ∪ C ∪ L), el(x) = {IdEventoi, Prioridadi}, i = 0,..., n, n ∈
- ac, es una función que asigna la categoría de acceso de un elemento, a un usuario, es decir,
ac: ∀ Ui ∈ U, ∀ x ∈ (HD ∪ N ∪ C), ac(Ui, x) = CategoríaAccesoi
Conclusiones
El proceso de análisis de la influencia que tienen los diferentes elementos (tema objeto, interfaz, sistema de navegación) y los medios (diferentes formas de presentación) en el proceso de comprensión de un hiperdocumento puede adelantarse en forma organizada mediante la caracterización de los elementos del Espacio de Análisis. Este espacio resulta de considerar que:
Para la comprensión de hiperdocumentos se requiere la comprensión de tres elementos presentes en el mismo: el tema objeto de estudio o de presentación, la interfaz con el usuario, y el sistema de navegación.
El proceso de comprensión de cada uno de los tres elementos mencionados pasa por cuatro niveles: el léxico, el sintáctico, el semántico y el pragmático.
La presentación organizada, sistemática e integrada de los elementos por considerar en el diseño para la comprensión del hiperdocumento facilita el establecimiento de criterios de diseño.
Bibliografia
No hay comentarios.:
Publicar un comentario