Michael Bieber
Instituto de Tecnología de Nueva Jersey
University Heights, Newark, NJ 07102 EE.UU.
RESUMEN
Tomamos un enfoque de dos etapas para las aplicaciones de ingeniería para la World Wide Web. Primero, el ingeniero de software realiza un Análisis de Relación-Navegación, analizando una aplicación nueva o existente, específicamente en términos de sus relaciones internas e internas. Esto lo lleva a comprender mejor la complejidad y la riqueza de la aplicación, así como a proporcionar el tipo de acceso y metaconocimiento que desean los usuarios. Segundo, un motor dinámico de hipermedia (DHymE) genera automáticamente enlaces para cada una de estas relaciones y elementos de metaconocimiento en tiempo de ejecución, así como sofisticadas técnicas de navegación que no se encuentran a menudo en la Web (por ejemplo, visitas guiadas, descripciones generales, consultas estructurales) en parte superior de estos enlaces. Los enlaces y la navegación, así como las funciones de anotación, complementan la funcionalidad principal de la aplicación.
Motivación
A medida que la World Wide Web y sus herramientas de programación maduran, encontramos cada vez más aplicaciones analíticas con interfaces web y otros sitios web con contenido generado en lugar de creado a mano. Esto incluye la gran clase de sistemas heredados que las organizaciones se apresuran a convertir a interfaces web [Be95]. Este documento se refiere al diseño de aplicaciones para todos estos sistemas. También aborda el peligro de que los desarrolladores doten a estos sistemas con una escasez de enlaces en lugar de adornarlos con la rica capa de enlaces y oportunidades de navegación que la Web podría admitir [BV97].
Además, los desarrolladores de estas aplicaciones analíticas a menudo luchan con la necesidad de presentar información complicada de una manera que los usuarios puedan entender mejor. A menudo, los desarrolladores confiarán en técnicas de visualización intuitivas y en un buen diseño de interfaz de usuario. Estos enfoques no son triviales, y para algunas aplicaciones no se puede transmitir información lo suficientemente simple para todos los usuarios, especialmente los estudiantes, los principiantes y aquellos que no están familiarizados con los detalles de bajo nivel del dominio de la aplicación (como un gerente no técnico que debe tomar decisiones basadas en un trabajo de desarrollador). Incluso para aplicaciones con pantallas de información directas, los usuarios pueden tener preguntas sobre qué significa un elemento en particular o cómo se determinó. Lógicamente, cada elemento dentro de una aplicación web puede considerarse un posible punto de partida para la exploración de información. La capacidad de explorar una parte de la información con más detalle podría ayudar a los usuarios a resolver dudas o simplemente a comprender mejor ese elemento, así como el análisis o la visualización de la que forma parte. Es posible que los usuarios deseen profundizar en los valores de los datos y los símbolos que ven, las etiquetas en los gráficos o los formularios de entrada del usuario, las opciones en las listas emergentes, la información que los usuarios ingresan como entrada (antes de enviarla) o incluso en los comandos del menú y otros controles. pueden invocar.
Para complicar el trabajo del desarrollador, los usuarios a menudo tienen diferentes modelos mentales de una aplicación (y su dominio subyacente) que el desarrollador (analista de aplicaciones o ingeniero de software). Incluso cuando los desarrolladores trabajan en estrecha colaboración con los usuarios, el resultado final puede no ser igualmente intuitivo para todos los usuarios o atender igualmente bien las tareas individuales de cada usuario. Un usuario puede
desear acceder a una pantalla, función o información en particular que cree que es inmediatamente relevante para la tarea en cuestión, pero que el sistema no hace accesible desde la pantalla actual o en las inmediaciones.
Proporcionar enlaces que representan relaciones de aplicación que le dan al usuario acceso a lo que él o ella quiere es uno de los propósitos principales de hipermedia. Tomamos un enfoque de dos etapas para las aplicaciones de ingeniería para la World Wide Web. Primero, el desarrollador realiza un Análisis de Relación-Navegación, analizando una aplicación existente o nueva específicamente en términos de sus interrelaciones e interrelaciones. Esto lo lleva a comprender mejor la complejidad y la riqueza de la aplicación, así como a proporcionar el tipo de acceso y metaconocimiento que desean los usuarios. Segundo, un motor dinámico de hipermedia (DHymE) genera automáticamente enlaces para cada una de estas relaciones y elementos de metaconocimiento en tiempo de ejecución, así como sofisticadas técnicas de navegación que no se encuentran a menudo en la Web (por ejemplo, visitas guiadas, descripciones generales, consultas estructurales) en parte superior de estos enlaces. Los enlaces y la navegación, así como las funciones de anotación, complementan la funcionalidad principal de la aplicación [BK95, Bi98].
Análisis de relación-navegación
La técnica de Análisis de Relación-Navegación (RNA) tiene 5 pasos:
(1) análisis de partes interesadas
(2) análisis de elementos
(3) Análisis de relaciones y metaconocimiento.
(4) análisis de navegación
(5) Análisis de la relación y metaconocimiento.
El ARN tiene dos propósitos principales. Por sí solo, un análisis de relación ayudará al desarrollador a formar una comprensión más profunda de la aplicación. Esto ocurre principalmente en los pasos 1-4. El desarrollador debe decidir cuál de estas relaciones implementará realmente. Algunos pueden proporcionar sólo un beneficio marginal. Otros pueden ser muy costosos o difíciles de implementar. Estas decisiones tienen lugar en el último paso.
Si bien es bastante útil en su forma actual, pretendemos desarrollar aún más la técnica de ARN produciendo pautas específicas para cada paso y reduciendo el rango de opciones que el desarrollador debe considerar dentro de los pasos 2 y 3 del análisis. Estos refinamientos deberían hacer que el análisis sea más sistemático y más fácil de realizar, al tiempo que permite que permanezca necesariamente abierto.
Paso 1: Análisis de partes interesadas
El propósito del análisis de las partes interesadas es identificar la audiencia de la aplicación. Saber quién estará interesado en una aplicación ayuda al desarrollador a determinar ampliamente la gama completa de elementos y relaciones importantes, y luego centrarse en estos específicamente. Especialmente aquellas aplicaciones con acceso web público tienen una gama mucho más amplia de partes interesadas de lo que muchos imaginan. De hecho, muchos desarrolladores encuentran que esta es la parte más esclarecedora del ARN. El desarrollador también debe identificar y comprender las tareas que cada tipo de usuario querrá realizar dentro de la aplicación. Esto ayudará al desarrollador a enfocarse en áreas específicas durante los pasos de ARN que siguen.
Paso 2: Análisis de elementos
Aquí el desarrollador enumera todos los elementos potenciales de interés en la aplicación. En un nivel, estos incluyen todos los tipos de elementos mostrados en cualquier visualización en línea (pantallas de información, formularios, documentos y cualquier otro tipo de visualización), así como las pantallas, formularios y documentos en sí. La forma más fácil de comenzar es examinar cada pantalla (o maqueta) e identificar cada valor y etiqueta que contiene. Tenga en cuenta que el desarrollador debe identificar tipos o clases de elementos, no instancias individuales. Los tipos de relación que discutimos en el paso 3 son todos para tipos específicos de elementos. En el dominio de análisis de decisiones, por ejemplo, estos incluyen “modelo” y “valor de datos” en lugar de modelos o valores de datos específicos.
Paso 3: Análisis de relaciones
El análisis de relaciones se refiere a las interrelaciones, las relaciones internas y el metaconocimiento. El desarrollador debe considerar cada elemento de interés identificado en el paso anterior en términos de cada uno de los siguientes tipos generales de relaciones, para cada grupo de partes interesadas. Ciertas relaciones serán útiles solo para ciertas partes interesadas, y el motor de hipermedia las filtrará. Las relaciones pueden llevar a información dentro y fuera de la aplicación. Los desarrolladores no deben sentirse limitados por las consideraciones del mundo real sobre la disponibilidad o el costo y el esfuerzo de implementación. En este paso, deben ejercer su creatividad de la manera más completa posible. Solo en el paso 5 deben considerar cómo implementar las relaciones y el metaconocimiento encontrado.
Actualmente, el ARN ayuda a los desarrolladores a identificar los siguientes tipos de relaciones y metaconocimiento dentro de una aplicación: esquema, proceso, operación, estructural, descriptivo, paramétrico, estadístico, colaborativo y ordenando relaciones. [Bi98] da más detalles para cada uno. Bieber y Vitali [BV97] muestran cómo varios de estos tipos de relaciones generales pueden complementar una factura de ventas en línea. [Bi98] muestra cómo pueden complementar un sistema de soporte de decisiones de modelado matemático.
Paso 4: Análisis de navegación
Una vez que identificamos las relaciones, podemos pensar en cómo el usuario podría acceder a ellas. La implementación más sencilla haría de cada relación un enlace y luego proporcionaría un recorrido simple (los usuarios seleccionan un ancla y un enlace, y el sistema muestra el destino del enlace). Pero ciertos tipos de relaciones se prestan a una navegación más sofisticada. El concepto de hipermedia incluye muchas otras funciones de navegación basadas en relaciones o enlaces. Estos incluyen visitas guiadas y senderos, descripciones generales y consultas estructurales [BVA97, Ni95]. En este paso del ARN, el desarrollador debe decidir qué características de navegación podrían servir mejor las necesidades de los interesados.
Paso 5: Análisis de la implementación de relaciones y navegación
Claramente, el paso 3 puede generar muchas relaciones y el paso 4 puede generar muchas oportunidades de navegación posibles. En este paso, el desarrollador debe decidir qué implementa realmente. Este paso no es la implementación real, simplemente la decisión lógica de qué relaciones implementar. Los diseñadores deben considerar los costos y beneficios (reales y marginales) de implementar y mostrar cada uno. Separamos este paso de los pasos 3 y 4 para que el diseñador pueda ejercer todos sus talentos creativos allí sin restricciones por consideraciones reales. El diseñador luego escribe una regla de mapeo (usando nuestro formato especificado) para cada una de las relaciones a implementar. Las reglas de asignación especifican los comandos o algoritmos para encontrar el punto final de cada relación.
DHymE (Dynamic Hypermedia Engine)
El motor de hipermedia DHymE se ejecuta por separado de la aplicación de destino. Escribimos un programa envoltorio para cada aplicación para integrarlo en nuestra arquitectura de motor. Las aplicaciones o sus envoltorios luego se conectan a DHymE a través de un servidor proxy web. DHymE intercepta todos los mensajes que pasan entre la aplicación y la interfaz de usuario, y utiliza las reglas de asignación especificadas anteriormente para asignar cada elemento apropiado del mensaje a un nodo o ancla hipermedia. Nuestro contenedor de navegador web integra estos anclajes en el documento que se muestra y lo pasa a través del servidor proxy al navegador web del usuario. Cuando el usuario selecciona un ancla, el envoltorio del navegador lo pasa a DHymE, que devuelve una lista de posibles enlaces (uno para cada relación apropiada según lo determinado por las reglas de asignación). Si el usuario selecciona un comando de aplicación normal (asignado a un enlace de operación), DHymE pasa el comando a la aplicación para su procesamiento. Si el usuario selecciona un enlace de motor de hipermedia (por ejemplo, para crear una anotación), DHymE lo procesa por completo. Si el usuario selecciona un esquema complementario, proceso, operación, estructural, descriptivo, información o relación de ocurrencia, DHymE infiere los comandos de aplicación apropiados, las operaciones de metaplicación (por ejemplo, a nivel de sistemas operativos o de esquema) o las operaciones del motor de hipermedia que Producir la información deseada. Si el usuario selecciona una anotación creada por el usuario, DHymE la recupera. Por lo tanto, DHymE proporciona automáticamente todos los enlaces de hipermedia (así como la navegación) a las aplicaciones, que permanecen inconscientes de la hipermedia y, de hecho, a menudo sin cambios. Actualmente estamos integrando varias aplicaciones con DHymE, dándole a cada uno una interfaz web o complementando su interfaz web existente: un sistema de seguimiento de solicitudes de personal, un sistema de gestión de base de datos relacional, un sistema de gestión de modelos matemáticos, un sistema de análisis de hoja de cálculo de transporte y un criterio múltiple herramienta de análisis de apoyo a la decisión. [Bi98] describe estas ideas y un prototipo anterior, no web, de DHymE con más detalle. [Bi97, CB97] también proporciona algunos antecedentes sobre el motor.
Conclusión
Esperamos que nuestra contribución más duradera sea convencer con éxito a los desarrolladores de aplicaciones web (tanto nuevas como transportadas desde otros entornos informáticos) para que aprovechen al máximo la vinculación de sus aplicaciones. Una y otra vez, los diseñadores nos han dicho que el ARN les ha mostrado enlaces que nunca imaginaron en sus propias aplicaciones. Identificarlos es el primer paso necesario hacia la implementación. Implementado de forma pensada, las funciones de enlace y navegación de la Web pueden contribuir en gran medida a reducir la complejidad de las aplicaciones para los usuarios. El ARN brinda a los desarrolladores una herramienta para identificar oportunidades para enlaces complementarios dentro de las aplicaciones. El motor de hipermedia DHymE genera automáticamente estos enlaces, con poco o ningún cambio en la aplicación.
Expresiones de gratitud
Reconocemos con gratitud los fondos para esta investigación del programa de becas de la facultad JOVE de la NASA, del Centro de Investigación Multimedia de Nueva Jersey, del Centro Nacional de Transporte y Productividad Industrial del Instituto de Tecnología de Nueva Jersey (NJIT), del Departamento de Transporte, por la Comisión de Ciencia y Tecnología de Nueva Jersey, así como subvenciones de la Fundación Sloane y la Fundación AT&T, y el programa NJIT SBR.
Referencias
[Be95] BENNETT, K. Sistemas heredados: hacer frente al éxito. IEEE Software, enero de 1995, 19-23.
[Bi97] BIEBER, M., Motor de hipertexto: Soporte para aplicaciones computacionales, Nota técnica, 1997.
[Bi98] BIEBER, M., Supplementing Applications with Hypermedia, en presentación, 1998. [BK95] BIEBER, M. Y KACMAR, C. Diseño de soporte de hipertexto para aplicaciones computacionales. Comunicaciones de la ACM 38 (8), 1995, 99-107.[BV97] BIEBER, M. y VITALI, F. (1997). Hacia el apoyo a la hipermedia en la World Wide Web. IEEE Computer 30 (1), 1997, 62-70.
[BVA97] BIEBER, M., VITALI, F., ASHMAN, H., BALASUBRAMANIAN V., y OINAS- KUKKONEN, H. Hipermedia de cuarta generación: algunos enlaces faltantes para la World Wide Web. Revista Internacional de Human Computer Studies 47, 1997, 31-65.
[CB97] CHIU, C. Y BIEBER, M., Un contenedor genérico de mapeo dinámico para soporte de sistema de hipertexto abierto de aplicaciones analíticas, Procesos de hipertexto, ACM Press, Nueva York, NY, abril de 1997, 218-219. [Ni95] NIELSEN, J. Multimedia e hipertexto: Internet y más allá. Profesional AP, 1995.
Original Source: https://web.njit.edu/~bieber/web-engineering.html
