Aixa: noviembre 2013

6.1. Modelos Abstractos Para Diseñar Hiperdocumentos

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.

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).

Las metodologías orientadas a objetos son especialmente indicadas para este fin (Lange, 1994; Schwabe 1995) ya que resulta muy natural considerar a los nodos y enlaces de un hiperdocumento como "objetos" y "relaciones" respectivamente.

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:

a. 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

b. 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).

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 u 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 (figura 1).

Un modelo involucra principalmente: El orden en el cual las actividades son llevadas a cabo, y las guías para hacer la transición entre etapas.

Los principales modelos de desarrollo son:

• Cascada

• “V”

• Espiral

• Incremental

• Otros

6.1.1. Modelo del ciclo de desarrollo del sistema

Modelo Cascada: Algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.

Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente.

El modelo en V: Es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. La codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.

Modelo Espiral: Propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

El modelo incremental: Fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

· Método de las comparaciones limitadas sucesivas.

· Ciencia de salir del paso.

· Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos (Figura 1), el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

El modelo de desarrollo de Sistemas, entonces, es la organización, administración e integración de personas y la información que ellos generan para la evolución de un sistema o producto.

6.1.2. Justificación de la necesidad de un modelo

La Ingeniería de Software surge como la aplicación de modelos y formas de la ingeniería tradicional a la práctica de construir productos de software; situación que ha condicionado su accionar al tener como norte las precisiones y seguridades que en otros ámbitos tiene la ingeniería.

La hipermedia surge como resultado de la fusión de dos tecnologías, el hipertexto y la multimedia. El hipertexto es la organización de una determinada información en diferentes nodos, conectados entre sí a través de enlaces. Los nodos pueden contener sub-elementos con entidad propia. Un hiperdocumento estaría formado por un conjunto de nodos conectados y relacionados temática y estructuralmente.

La tecnología multimedia es la que permite integrar diferentes medios (sonido, imágenes, secuencias...) en una misma presentación. La hipermedia, por tanto, es la tecnología que nos permite estructurar la información de una manera no-secuencial, a través de nodos interconectados por enlaces. La información presentada en estos nodos podrá integrar diferentes medios. (Texto, sonido, gráficos...).

Estos conceptos (hipermedia, hipertexto y multimedia) suelen ser confundidos entre sí, debido principalmente a su estrecha relación semántica. Por ello, es normal encontrar literatura en la que se utilice alguno de estos términos para referirse a cualquiera de los otros dos. El diseño de sistemas hipermedia o hiperdocumentos puede ser abarcado desde una doble vertiente: El diseño de la información y el diseño de la navegación.

Históricamente han surgido varios enfoques que buscan abordar de manera sistemática, la planificación, análisis, diseño e implementación de los proyectos de desarrollo de software, sean estos de gran escala y pequeñas aplicaciones, software a la medida o productos de software. Cada uno de estos enfoques tiene su raíz en el pre-concepción dominante en su época y, sobre todo, en la búsqueda incesante de mejoras a los enfoques precedentes.

Permite llevar un mayor control sobre las tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, según parezca que van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.

6.2. Retrospectiva de los modelos para hipermedia

El diseño de sistemas hipermedia o hiperdocumentos puede ser abarcado desde una doble vertiente: El diseño de la información y el diseño de la navegación.

Diseño de la Información: El usuario, ante un nodo (por ejemplo, una página web), realiza un barrido visual de éste, ojeando "a saltos" la pantalla, discriminando automáticamente la información que no le interesa y centrando su atención en la que si. Un buen diseño de la información, desde el punto de vista organizativo y de su usabilidad, será aquel que ayude al usuario a encontrar la información que busca de la forma más fácil, rápida y cómoda posible.

Diseño de la Navegación: El diseño de la navegación consiste en definir la arquitectura de nuestro hipermedia: elementos de interacción entre el usuario y el sistema, enlaces y tipos de enlaces entre los nodos, agrupación de los nodos por categorías o propiedades, y respuestas del sistema ante peticiones del usuario.

6.2.1. Modelos basados en grafos

Los modelos basados en redes o grafos proporcionan soluciones a veces espectaculares a problemas de la más variada naturaleza.

La presentación de los resultados tiene la ventaja de ser perfectamente comprensible, incluso para una persona poco iniciada en las matemáticas. Además, la teoría de grafos permite una presentación visual clara de muchos problemas que admiten también otro tipo de resoluciones.

Son sistemas que extraen estructuras de grafos a partir de los datos conocidos y que aplicaran diversos algoritmos de grafos para generar predicciones. Veremos tres tipos de grafos:

· Grafo bipartito de ítems y usuarios. Enlaces ponderados respecto a la valoración de un usuario para un ítem, numero de reproducciones

· Grafo de ítems.

o Enlaces ponderados cuando tienen usuarios en común.

o Mayor peso a mayor número de usuarios en común.

o Red de blogs: enlaces correspondientes a hiperenlaces no ponderados con información de preferencias de usuarios.

· Grafo con información social y de etiquetado.

6.2.2. Modelos basados en redes de Petri

El concepto de red de Petri apareció en 1962 con la tesis doctoral de Carl Adam Petri ``Comunicación con Autómata'' en la Universidad de Bonn. A partir de entonces se difundió en Europa y Estados Unidos, y ya en 1970 aparecieron grupos de investigación que incorporaban las redes de Petri a sus trabajos y/o que se dedicaban a estudiar sus propiedades. Con todo el trabajo acumulado se crearon ciclos de conferencias, libros, actas y revistas en esta área. Aunque no hay memorias y actas de todas las conferencias, los artículos más importantes de éstas, se condensaron en varios libros y revistas.

Las redes de Petri se pueden incorporar informalmente en cualquier área o sistema que pueda describirse gráficamente como diagrama de flujo y que necesitan algunos medios de representar actividades paralelas o concurrentes. Particularmente, en el área de desarrollo de software, las redes de Petri son una herramienta de validación que puede aplicarse en distintas etapas en el desarrollo de sistemas.

Sin embargo, el punto débil de las redes de Petri radica en la complejidad del problema, esto es, los modelos basados en redes de Petri, siempre tienden a ser muy grandes para su análisis. Con el fin de solucionar este problema se han desarrollado técnicas de reducción y extensiones a las redes de Petri. Por lo general, para aplicar las redes de Petri a un problema, se le realizan modificaciones o restricciones.

Una red de Petri es un grafo orientado con dos tipos de nodos: lugares (representados mediante circunferencias) y transiciones (representadas por segmentos rectos verticales). Los lugares y las transiciones se unen mediante arcos o flechas.

Un arco une siempre lugares con transiciones y nunca dos lugares o dos transiciones. Una transición puede ser destino de varios lugares y un lugar puede ser el destino de varias transiciones. Una transición puede ser origen de varios lugares y un lugar puede ser origen de varias transiciones. Los lugares pueden presentar marcas (una marca se representa mediante un punto en el interior del círculo).

Cada lugar tiene asociada una acción o salida. Los lugares que contienen marcas se consideran lugares activos. Cuando un lugar está activo sus salidas están a uno. A las transiciones se les asocia eventos (funciones lógicas de las variables de entrada). Una transición se dice que está sensibilizada cuando todos sus lugares origen están marcados. Cuando ocurre un evento asociado a una transición (la función lógica se hace uno), se dice que la transición está validada.

6.2.3. Modelos expresados en lenguaje formal

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 hipertextual 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 hipertextual, 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:

· El modelo de Dexter

· El modelo HAM o modelo de arquitectura a 3 niveles de Campbell y Goodman

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:

· El modelo Trellis de Stotts y Furuta

· El Modelo Formal de B. Lange

· El Modelo Tower, orientado a objetos de De Bra, Houben y Kornatzky

· El modelo de Amsterdam

· El modelo HDM

· El modelo RMM

· Modelo OOHDM

· El modelo EORM

· El lenguaje UML

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.

6.2.4 Utilización de notaciones gráficas

· El DIAGRAMA DE FLUJO u ORGANIGRAMA es la representación gráfica más ampliamente usada para el diseño procedimental. Como ya hemos visto en el gráfico anterior, la notación es la siguiente:

Las construcciones estructuradas pueden estar anidadas unas en otras, desarrollando de esta forma esquemas lógicos complejos.

· El DIAGRAMA DE CAJAS

· NOTACIONES TABULARES DE DISEÑO: Las Tablas de Decisión nos permiten representar las condiciones y acciones que se han de contemplar en un módulo. Para construir la tabla de decisión se define su tamaño máximo, eliminando cualquier situación imposible. Para desarrollar una tabla de decisión se aplican los siguientes pasos:

1) Listar todas las acciones que puedan realizarse.

2) Listar todas las condiciones que puedan afectar a la condición.

3) Rellenar todas las alternativas de la condición, eliminando posteriormente las situaciones imposibles, contradictorias y redundantes.

4) Asociar conjuntos específicos de condiciones con acciones determinadas. Es decir, determinar las reglas.

5) Combinar las reglas donde sea aparente que una alternativa no implique diferencias en la salida.

· NOTACIÓN ALGORÍTMICA - LENGUAJE DE DISEÑO DE PROGRAMAS (LDP): El LDP es el pseudocódigo de uso general, aunque existen LDP comerciales que permiten traducirlo a representación gráfica (ej.: Diagramas de flujo). La diferencia entre un LDP y un lenguaje de programación de alto nivel real se encuentra en el uso de texto descriptivo en las sentencias del LDP, por lo que no puede ser compilado. Un lenguaje de diseño de programas debe tener las siguientes características:

a) Una sintaxis fija de palabras clave que permitan construir todas las construcciones estructuradas, declarar datos y establecer características de modularidad.

b) Una sintaxis libre en lenguaje natural para describir las características del procesamiento.

c) Facilidades para la declaración de datos, incluyendo estructuras de datos simples y complejos.

d) Un mecanismo de definición de subprogramas y de invocación, soportando los distintos modos de descripción de interfaces.}

Normalmente se utiliza un lenguaje de programación de alto nivel como base para el LDP.

6.3. Requisitos de un modelo para hipermedia

Los métodos definen las etapas y actividades necesarias para efectuar la construcción completa de un sistema hipermedia la mayoría definen con los siguientes nombres las etapas:

Análisis conceptual. Trata de la especiación del dominio del problema, a través de la dentición de datos y sus relaciones.

Diseño navegacional. Establece los caminos de acceso a la información y sus permisos de visibilidad.

Diseño de la presentación. Deﬁne como se muestra la información en la interfaz de usuario.

Implementación. Es la construcción del software a partir de los artefactos generados en las etapas previas.

6.3.1. Requisitos derivados de la definición del modelo

La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.

Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.

El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:

1. Reconocimiento del problema

2. Evaluación y síntesis

3. Modelado

4. Especificación

5. Revisión

Todos los métodos de análisis se relacionan por un conjunto de principios operativos:

1. Debe representarse y entenderse el dominio de la información de un problema.

2. Deben definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos),

4. Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).

5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.

Además de los principios operativos mencionados anteriormente, se sugiere un conjunto de principios directrices para la ingeniería de requerimientos:

1. Entender el problema antes de empezar a crear el modelo de análisis.

2. Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.

3. Registrar el orden y la razón de cada requerimiento,

4. Usar múltiples planteamientos de requerimientos.

5. Priorizar los requerimientos.

6. Trabajar para eliminar la ambigüedad.

Un ingeniero de software que se apegue a estos principios es muy probable que desarrolle una especificación de software que represente un excelente fundamento para el diseño.

6.3.2. Requisitos derivados de la hipermedia

a) Interactividad y control del usuario. Hipermedia permite determinar al usuario la secuencia mediante la cual acceder a la información. Puede, también, añadirla o introducirla haciéndolo más significativo para él (colaboración); y le permite, también, construir y estructurar su propia base de conocimiento. El nivel del control del usuario varía con el sistema y sus propósitos. Pero, en general, el usuario controla, en base a una continua y dinámica interacción, el flujo de la información (Borsook y Higginbotham-Wheat, 1991): Puede acelerar/desacelerar, cambiar de dirección, ampliar los horizontes de su información, argüir /combatir, etc...

b) Entorno constructivo. Los sistemas hipermedia proporcionan herramientas flexibles de navegación. Algunos de estos sistemas se han convertido en entornos de autor y son utilizados para crear materiales de instrucción basados en el ordenador, para contener las anotaciones personales o la organización de la información, para la comunicación con lo semejante,... También son usados como herramienta de aprendizaje cognitivo para la organización y el almacenamiento del conocimiento base de los propios usuarios. Desde esta perspectiva una concepción amplia de hipermedia lo concebiría como un entorno de software para construir o expresar conocimiento, colaboración o resolver problemas.

c) Estructuras de Hipermedia. Uno de los momentos más importantes en la creación de materiales hipermedia es decidir cómo y cuánto estructurar la información en la base de conocimiento (Jonassen y Wang, 1990; Romiszowki, 1991; Kappe, Maurer y Sherbakov, 1993). La respuesta depende, en parte, de la utilización que se va a hacer del sistema: La variabilidad de las aplicaciones exige la existencia de diferentes estructuras de acceso e información.

- Hipermedia no estructurado, en cuya estructura nodo-conexión sólo son utilizadas las conexiones referenciales. Dos nodos están conectados al contener un nodo una referencia a la información contenida en el otro. Proporciona acceso aleatorio desde cualquier nodo a otro con el que esté conectado. La mayor tarea, en relación al diseño, es identificar los conceptos o fragmentos de información indicados y comprendidos en cada nodo. Junto a esto, la estructura organizativa se fundamenta en sistemas similares a los de análisis de textos que analizan libros de texto (lista de contenidos, índices y palabras clave) para los términos o ideas importantes.

- Hipermedia estructurado, que implica una organización explicita de nodos y conexiones asociativas. En el diseño de hipermedia estructurado, el diseñador es el que dice si hay una estructura de la materia tratada a señalar en las estructuras de conexiones y estructura de nodos. Hipermedia estructurado contiene series de nodos, cada una de ellas interconectadas e introducidas explícitamente para representar la estructura de la información. Se pueden utilizar para ello varios modelos: Estructura semántica (refleja la estructura de conocimiento del autor o del experto); estructura conceptual (incluye contenido predeterminado por las relaciones entre las taxonomías); estructuras relacionadas con las tareas (facilitan el cumplimiento de una tarea); estructuras relacionadas con el conocimiento (basadas en el conocimiento del experto o del estudiante); estructuras relacionadas con los problemas (simulan problemas o tomas de decisiones). La configuración proporcionada por las características anteriormente analizadas, las relaciones que entre las mismas y otras no analizadas se establecen, podemos considerarlas como las variables de un sistema hipermedia. Las variables que se manejan en un sistema hipermedia dan fe de la complejidad del sistema y de la estructura y organización que presenta.

6.4. Modelo genérico para hipermedia: Labyrinth

El modelo Labyrinth [Díaz 94], [Díaz 01], es el único junto al modelo OOHDM capaz de responder a eventos genéricos, o en términos propios del modelo, capaz de especificar comportamientos dinámicos. El modelo

Labyrinth es un modelo para el diseño de aplicaciones hipermedia, siendo sus características más relevantes:

- Permitir diseñar aplicaciones hipermedia independientes de la plataforma.

- Permitir la categorización, generalización y abstracción de información dispersa y heterogénea en distintos niveles interconectados.

- Permite la representación de todo tipo de información multimedia, temporización, sincronización, etc.

- Permite la creación de vistas personales en hiperdocumentos multiusuarios para grupos y usuarios individuales.

- Permite la inclusión de mecanismos de seguridad según la definición de seguridad dada por el DTI (Department of Trade and Industry of the USA).

6.4.1. Elementos del modelo

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.2. Notación del modelo Labyrinth

HDB = (U, N, C, A, L, B, E, lo, al, el, ac)

Dónde:

- 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:

∀ Ci ∈ C, ∀ Nj ∈ N | i = 0,..., n, n ∈ ℕ, j = 0,..., m, m ∈ ℕ, lo(Ci, Nj) = { Posicióni, Tiempoi }

Dónde:

Posicióni es la posición del contenido en el nodo

Tiempoi = {Comienzoi, Duracióni} 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 ∈ ℕ,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

Vídeo complementario

Conclusión:

La tecnología hipermedia brinda muchas posibilidades en el ámbito documental para la producción de hiperdocumentos que incorporen elementos multimedia que los hagan especialmente atractivos. Los avances en las tecnologías de almacenamiento de datos, como el CD-ROM, y de las telecomunicaciones, especialmente Internet, están facilitando la aparición de un gran número de productos hipermedia (enciclopedias, museos virtuales, periódicos en Internet, etc.) con una complejidad creciente. Por ello, es natural el interés que la comunidad dedicada al desarrollo hipermedial está prestando a las metodologías que recientemente han aparecido para racionalizar el proceso de construcción de estas aplicaciones mediante el desarrollo de modelos que faciliten su posterior mantenimiento y reutilización, y que garanticen la calidad final del producto. En este artículo se proponen precisamente algunas técnicas para el modelado conceptual de la documentación multimedia e hipermedia. Su utilidad se pondrá de manifiesto si se incorporan en los entornos de edición hipermedia facilidades para diseñar y verificar los modelos e, incluso, generar automáticamente los documentos hipermediales a partir de esos modelos

Bibliografía

· http://ldc.usb.ve/~abianc/hipertexto.html

· http://www.monografias.com/trabajos34/ingenieria-software/ingenieria-software.shtml

· http://www.uclm.es/profesorado/licesio/Docencia/mcoi/Tema5_guion.pdf

· http://ir.ii.uam.es/saul/wp-content/uploads/2011/06/presentacion_eit1.pdf

· http://computacion.cs.cinvestav.mx/~ameneses/pub/tesis/mtesis/node6.html

· http://www.uhu.es/diego.lopez/AI/auto_trans-tema3.PDF

· http://www.hipertexto.info/documentos/arquitec.htm

· http://ingenieriacesmag.blogspot.mx/p/notaciones-graficas-de-diseno.html

· http://riunet.upv.es/bitstream/handle/10251/3884/tesisUPV2961.pdf

· http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

· http://tecnologiaedu.us.es/nweb/htm/pdf/gte5.pdf