u6 modelos para el diseño de hiperdocumentos
TRANSCRIPT
Índice
PRESENTA
CASTAÑEDA QUIROZ SILVIA VIRIDIANA
CATEDRATICO
RITA HERNANDEZ FLORES
TRABAJO:
UNIDAD 6
INSTITUTO TECNOLOGICO DE ORIZABA
MULTIMEDIA Y REALIDAD
VIRTUAL
Índice
U6 Modelos Para El Diseño De Hiperdocumentos…………………………………..3
6.1. Modelos Abstractos Para Diseñar Hiperdocumentos…………………………3
6.1.1. Modelo del ciclo de desarrollo del sistema……………………………………6
Modelo Cascada………………………………………………………………...…………6
El modelo en V……………………………………………………………...……………...6
El modelo incremental………………………………………………...………………….7
6.1.2. Justificación de la necesidad de un modelo…………………………………..8
6.2. Retrospectiva de los modelos para hipermedia………………………………...9
6.2.1. Modelos basados en grafos…………………………………………………….10
6.2.2. Modelos basados en redes de Petri……………………………………………10
6.2.3. Modelos expresados en lenguaje formal……………………………………..12
6.2.4 Utilización de notaciones gráficas………………………………………………14
6.3. Requisitos de un modelo para hipermedia……………………………………..15
6.3.1. Requisitos derivados de la definición del modelo…………………………..16
6.3.2. Requisitos derivados de la hipermedia………………………………………..18
6.4. Modelo genérico para hipermedia: Labyrinth…………………………………..19
6.4.1. Elementos del modelo…………………………………………………………….20
6.4.2. Notación del modelo Labyrinth………………………………………………….20
Conclusión………………………………………………………………………………….21
Bibliografía…………………………………………………………………………………21
U6 Modelos Para El Diseño De Hiperdocumentos
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).
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
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.
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.
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. Define 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 ∈ ℕ
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