El desarrollo de aplicaciones web involucra decisiones no triviales de diseño e implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la división de tareas. Los problemas involucrados, como el diseño del modelo del dominio y la construcción de la interfaz de usuario, tienen requerimientos disjuntos que deben ser tratados por separado.

El alcance de la aplicación y el tipo de usuarios a los que estará dirigida son consideraciones tan importantes como las tecnologías elegidas para realizar la implementación. Así como las tecnologías pueden limitar la funcionalidad de la aplicación, decisiones de diseño equivocadas también pueden reducir su capacidad de extensión y reusabilidad. Es por ello que el uso de una metodología de diseño y de tecnologías que se adapten naturalmente a ésta, son de vital importancia para el desarrollo de aplicaciones complejas.

Existen en la actualidad tecnologías ampliamente usadas para el desarrollo de aplicaciones web, pero muchas de ellas obligan al desarrollador a mezclar aspectos conceptuales y de presentación.

La elección de tecnologías complejas demora el proceso e incrementa los costos, pero en ocasiones permite adecuarse a metodologías de diseño más fácilmente. Tal es el caso de las tecnologías orientadas a objetos, las cuales tienden a demorar el desarrollo en etapas tempranas. El tiempo de desarrollo en la actualidad es crítico, tanto por razones de marketing como por límites en el presupuesto y los recursos

MARCO TEÓRICO

1.1. EORM

Es una Metodología de Relación entre Objeto (Enhanced Object Relationship Methodology), es definido por un proceso iterativo que se concentra en el modelado orientado a objetos por la representación de relaciones entre los objetos (acoplamientos) como objetos, es por ello que fue una de las primeras propuestas para Web centrada en el paradigma de la orientación a objetos. Se basa en muchas de las ideas que se definen en HDM, pero las traslada a la orientación a objetos. La adopción del enfoque orientado a objetos garantiza todas las ventajas reconocidas para esta técnica de modelado, como la flexibilidad (posible existencia de múltiples formas de relaciones entre nodos) y la reutilización, por la existencia de una librería de clases de enlaces que pueden ser reutilizados en diferentes proyectos de desarrollo hipermedia.

Para automatizar la aplicación de la metodología EORM, su autor ha desarrollado, en los laboratorios de investigación de IBM, una herramienta denominada ODMTool que, junto a un generador comercial de Interfaces Gráficas de Usuario denominado ONTOS Studio y un Sistema de Gestión de Base de Datos Orientado a Objetos (SGBDOO), permite el diseño interactivo de esquemas EORM y la generación de código fuente, inicialmente en C++, de las clases incluidas en estos esquemas. El SGBDOO ofrece un repositorio de objetos que permite la compartición de la información de los esquemas entre las herramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermediales desarrolladas.

Esta metodología tiene las siguientes ventajas: Encajamiento de relaciones semánticas en construcciones extensibles, pudiendo participar en otras relaciones pudiendo ser parte de bibliotecas reutilizables. EORM distingue dos tipos de relaciones orientadas a objetos: Relaciones de generalización y relaciones definidas por el usuario. Mientras que los primeros se concentran como en la semántica asociada entre ellas, los segundos confían totalmente en la especificación del usuario

La semántica de vínculos básicos de clases que se manejan, son las siguientes de manera resumida:

SimpleLink

Es la raíz vínculo básica de clase que proporciona capacidad de interconexión, incluido funciones para la creación, supresión y recorrido

NavigationalLink

Proporciona mecanismos para enlaces hipermedia que incluye el almacenamiento de creación de tiempo e información histórica. Se hereda de simpleLink

NodeToNode

Es un vínculo que hereda de NavigationalLink y proporcionar un objeto a un objeto Hipermedia de vínculo de funcionalidad

SpanToNode

Se hereda de NavigationalLink. Vincula el contenido de un objeto a otro objeto.

StructureLink

Se hereda de SimpleLink y la raíz de los vínculos estructurales. Se inserta después creación en el contexto estructural.

SetLink

Es una structureLink que proporciona acceso a un objeto en una desordenada colección de objetos.

ListLink

Es un structureLink que proporciona acceso a un objeto en una colección ordenada de objetos.

1.1.1. Fases

Podemos mencionar que esta metodología consta de las siguientes fases según el siguiente diagrama de flujo:

1.1.1.1. Fase de Análisis

Se trata de orientar a objetos al sistema, sin considerar los aspectos hipermediales del mismo, obteniéndose para ello un Modelo de Objetos con la misma notación utilizada en OMT, que refleje la estructura de la información (mediante clases de objetos con atributos y relaciones entre las clases) y el comportamiento del sistema (a través de los métodos asociados a las clases de objetos)

1.1.1.2. Fase de Diseño

Procede a modificar el modelo de objetos obtenido durante el análisis añadiendo la semántica apropiada a las relaciones entre clases de objetos para convertirlas en enlaces hipermedia, obteniendo finalmente un modelo enriquecido, que su autor denomina EORM (Enhanced Object-Relationship Model), en el que se refleje tanto la estructura de la información (modelo abstracto hipermedial compuesto de nodos y enlaces) como las posibilidades de navegación ofrecidas por el sistema. sobre dicha estructura, para lo cual existirá un repositorio o librería de clases de enlaces, donde se especifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, que serán de tipo crear, eliminar, atravesar, siguiente, previo etc., así como sus posibles atributos (fecha de creación del enlace, estilo de presentación en pantalla, restricciones de acceso, etc.)

1.1.1.3. Fase de Construcción,

Se transformar los esquemas en código y guardados en una Base de Datos Orientada a Objetos, y en elaborar formularios de consulta de las clases con la ayuda de un editor gráfico de interfaces. Se genera el código fuente (por ejemplo en C#) correspondiente a cada clase y se prepara la Interface Gráfica de Usuario.

Las relaciones definidas en un modelo orientado a objetos pueden ser representadas por clases de enlaces hipermedia. Estas clases añaden a las relaciones del modelo objeto la semántica navegacional de la aplicación. Están organizadas en una jerarquía de herencia propuesta por el método bajo la forma de una biblioteca de clases. La semántica relativa a las propiedades hipermedia de las relaciones encuentra, por tanto, una representación en EORM bajo la forma de clases.

Toda la semántica de relaciones de aplicación se expresa por medio de enlaces hipermedia reagrupados en una jerarquía de clases y así, el comportamiento definido sobre los enlaces permite tener en cuenta una parte de la semántica de la navegación de la aplicación. También se permite alterar la propia estructura navegacional de la aplicación mediante operaciones de creación, destrucción o de modificación de elementos hipermedia. El modelo EORM se ha centrado, principalmente, en el enriquecimiento de los elementos hipermedia.

1.2. OOHDM

Es un Método de Diseño de Desarrollo en Hipermedia Orientado a Objetos (Object-Oriented Hypermedia Design Method) y abarca las cuatro actividades: El modelado conceptual, diseño navegacional, diseño abstracto de interfaz y la puesta en práctica. Estas actividades se relizan en una mezcla de estilo incremental, iterativo y basado en prototipos de desarrollo.

1.2.1. Fases

Los modelos orientados a objetos se construyen en cada paso que mejora los modelos diseñados en iteraciones anteriores y consta de las siguientes fases:

1.2.1.1. Fase Conceptual

Durante esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son modificados durante la ejecución, se podría usar un modelo de datos semántico estructural (como el modelo de entidades y relaciones). De este modo, en los casos en que la información base pueda cambiar dinámicamente o se intenten ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del modelo de objetos En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real.

1.2.1.2. Fase Navegacional

Se debe tener en mente que la generación de aplicaciones Web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones.

Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual. El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos. La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros. Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto

1.2.1.3. Fase de Interfaz Abstracta

Se debe tener las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, de cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas.

El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones Web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar.

En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia. El modelo de interfaz ADVs (Vista de Datos Abstracta) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación

1.2.1.4. Fase Implementación

Se tendrá en cuenta que el diseñador debe ya implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno Web, el diseñador debe decidir además qué información debe ser almacenada.

En los diagramas de clases navegacionales corresponden a vistas del esquema conceptual y los esquemas de contexto modelan el espacio de navegación incluyendo estructuras de acceso y contextos (que corresponde a un conjunto de instancias de una clase navegacional). Se podrían crear vistas parciales por usuario agrupando los contextos a partir de los tipos de usuarios que tienen acceso a los mismos. Las vistas por módulos o subsistemas no las modela de manera explícita, pero en los esquemas de contextos pueden modelarse fácilmente sub.-módulos

Construir la interfaz de una aplicación Web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. Esta metodología propone dedicar un tiempo importante en las fases previas a la implementación.

Esta inversión de tiempo está ampliamente justificada no sólo porque simplifica el proceso de desarrollo, facilitando el trabajo del equipo encargado de cada capa de la aplicación, sino también durante su mantenimiento y eventual extensión.

Son quizás estas últimas tareas las más difíciles de lograr con tecnologías tradicionales, y aún imposibles en muchos casos donde no existe diseño detallado y la implementación concentra conceptos heterogéneos muy difíciles de modificar.

1.3. SOHDM

Es un Método que Desarrolla Diseño en panoramas (scenario) Orientada a Objetos en Hipermedia (Scenario - based Object-oriented Hypermedia Design Methodology). Presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios.

Es una de las primeras propuestas para la web y brinda más importancia a la tarea de tratamiento de requisitos. Se caracteriza principalmente porque su ciclo de vida comienza con la aplicación de los escenarios como técnica de elicitación y definición de requisitos.

El proceso de definición de requisitos parte de la realización de un diagrama de contexto tal y como se propone en los diagramas de flujos de datos (DFD) de Yourdon (1989). En este diagrama de contexto se identifican las entidades externas que se comunican con el sistema, así como los eventos que provocan esa comunicación. La lista de eventos es una tabla que indica en qué eventos puede participar cada entidad. Por cada evento diferente, SOHDM propone elaborar un escenario. Estos son representados gráficamente mediante los denominados SACs2 (Scenario Activity Chart).

Cada escenario describe el proceso de interacción entre el usuario y el sistema cuando se produce un evento determinado, especificando el flujo de actividades, los objetos involucrados y las transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema, que es representado mediante un diagrama de clases. El proceso de SOHDM continúa reagrupando estas clases para conseguir un modelo de clases navegacionales del sistema.

Consiste en seis fases: análisis del dominio, modelado del objeto, diseño de la visión, diseño de la navegación, diseño de la puesta en práctica y construcción.

Esta metodología tiene semejanzas con, OOHDM y EORM donde se diferencian en el uso de panoramas, que describen las actividades en los acontecimientos y primitivas de flujos de actividades. Los panoramas se definen en la fase de análisis y se utilizan para modelar los objetos

1.3.1. Fases

A continuación detallaremos sus fases:

1.3.1.1. Fase de Análisis,

Se realizar un estudio de las necesidades de la aplicación, del entorno de trabajo y de los actores. La finalidad principal de esta fase es conseguir los escenarios que representen las actividades que se pueden llevar a cabo en el sistema.

1.3.1.2. Fase de Modelado de Objetos,

Se desarrolla un diagrama de clases que representa la estructura conceptual del sistema

1.3.1.3. Fase de Diseño de Vistas,

Se reorganizan los objetos en unidades navegacionales que representan una vista de los objetos del sistema.

1.3.1.4. Fase de Diseño Navegacional,

Se enriquecen dichas vistas definiendo los enlaces e hiperenlaces que existen en el sistema.

1.3.1.5. Fase de Diseño de la Implementación,

Se diseñan las páginas, la interfaz y la base de datos del sistema.

1.3.1.6. Fase de Construcción,

Se realiza la construcción de la base de datos del sistema. la que se implementa la aplicación.

Esta propuesta es hasta ahora la única que tiene en cuenta aspectos como la especificación de requisitos haciendo uso de los escenarios. Otra ventaja es que es un proceso sencillo de seguir, no obstante su nomenclatura es muy cerrada. Además es una propuesta donde se hacen uso de técnicas de modelado orientado a objetos, algo muy significativo ya que es adecuado para el desarrollo de este tipo de aplicaciones

1.4. WSDM

Es un Método de Diseño para Sitios Web (Web Site Design Method), donde hay un acercamiento al usuario que define los objetos de información basado en sus requisitos de información para el uso de la Web. En este método se definen una aplicación Web a partir de los diferentes grupos de usuarios que vaya a reconocer el sistema.

Propone cuatro etapas: modelo de usuario, diseño conceptual, diseño de la implementación e implementación. El tratamiento de requisitos se lleva a cabo en la etapa inicial, donde, en primer lugar, se identifican y clasifican los usuarios que van a hacer uso de la aplicación Web.

1.4.1. Fases

A continuación, se describen los requisitos de cada grupo de usuarios y sus fases.

1.4.1.1. Fase de Modelo de Usuario

Se intenta detectar los perfiles de usuarios para los cuales se construye la aplicación. Durante esta fase es necesario determinar:

¿Quién es el público objetivo? ¿Cómo será la visión de su sitio Web? ¿Cuáles son los objetivos de marketing de la empresa? ¿Cuáles son los objetivos de su sitio web? ¿Qué mensaje tiene su compañía quiere transmitir? ¿Cuál es el campo del negocio? ¿Cuáles son los estándares de la industria?

Una vez que tenemos una comprensión de su negocio y sus objetivos de la empresa, que hará recomendaciones a la mejor alcanzar sus metas. Nuestro proceso de planificación estratégica se creará un plan inicial de su sitio web. Se divide en dos subfases siguientes:

1.4.1.1.1. Clasificación de usuarios:

Se deben identificar y clasificar a los usuarios que van a hacer uso del sistema. Para ello, WSDM propone el estudio del entorno de la organización donde se vaya a implantar el sistema y los procesos que se vayan a generar, describiendo las relaciones entre usuarios y actividades que realizan estos usuarios. Para la representación gráfica de estas relaciones WSDM propone una especie de mapas de conceptos de roles y actividades

1.4.1.1.2. Descripción de los grupos de usuarios

Se describen con más detalles los grupos de usuarios detectados en la etapa anterior. Para ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que indican los requisitos de almacenamiento de información, requisitos funcionales y de seguridad para cada grupo de usuarios.

1.4.1.2. Fase de Diseño Conceptual

Se desarrolla el modelado conceptual no tiene el mismo significado que en OOHDM. Durante el modelado conceptual se realizan dos tareas a la vez: el modelado de objetos, que es lo que en OOHDM se llama modelo conceptual y el diseño de la navegación, que coincide con la idea del diseño navegacional de OOHDM, Este tipo de diseño de navegación en aplicaciones Web tiene una estructura muy jerárquica. La aplicación de diseño pasa a crear un coherente y eficiente modelado conceptual.

Pocas recomendaciones se dan en esta etapa, tales como la utilización de páginas de índice, derecho de información dividida en diversos tamaños, el uso de contexto y de la información y el uso de señales de navegación. La navegación modelo consiste en una serie de vías de navegación, uno para cada perspectiva expresando de forma en que los usuarios de una perspectiva particular puede navegar a través de la información disponible. WSDM describe en términos de los componentes y enlaces.

Distingue tres tipos de componentes de navegación, información y externos. Cada navegación consta de tres capas: contexto, navegación y capas de información. En WSDM puede existir más de un modelo de navegación, dependiendo de los roles de usuario detectados durante la primera fase

1.4.1.3. Fase de Diseño de Implementación

Se modela la interfaz para cada rol de usuario, Ahora que se tiene una versión definitiva del plan se puedan comenzar con la construcción del sitio web. Durante esta fase, se tendrá lugar lo siguiente:

La construcción de la arquitectura de navegación del sitio.

ü Creación de alta funcionalidad, teniendo como fin a la animación, pues hará que se propague por todas las páginas de los medios necesarios con sus los gráficos y el texto.

ü El código de los programas técnicos y la funcionalidad del sitio.

ü La creación y diseño de la página principal disponible

1.4.1.4. Fase de Realización de Implementación

Se codifican todos estos aspectos en el lenguaje concreto que se haya seleccionado. WSDM es también una propuesta viva que está cambiando y adaptándose a nuevos requisitos.

Preparamos el lanzamiento de la web teniendo en cuenta ¿Cuándo entrarían a nuestra web? Antes de la puesta en marcha vamos a garantizar lo siguiente:

ü Continuo y exhaustivas pruebas que garantizará un impecable final del sitio web.

ü Trabajo directamente con la empresa para garantizar la técnica y la usabilidad se cumplen las normas.

ü Velar el final del proyecto con la finalidad de ver si se han cumplido los requisitos planteados.

ü Crear una fecha de lanzamiento y el plan

WSDM se describe en términos de componentes y enlaces. Distingue tres tipos de componentes de navegación. Cada navegación consta de tres capas: contexto, la navegación y capas de información. El contexto es la capa superior de la navegación y a su vez la de información es la capa inferior. La capa de navegación conecta la capa de contexto y la capa de información. Para acceder a la información intermedia por componentes y los vínculos que se crean, tales como los índices. En la actualidad, es uno de los trabajos más interesantes y novedosos que se le está aplicando es el desarrollo de una herramienta CASE que permita aplicar el ciclo de vida de desarrollo de WSDM

1.5. RNA

Es un método de Análisis de Navegación Relacional (Relationship Navigational Analysis), que define una secuencia de pasos que se utilizarán para el desarrollo de la Web. Es especialmente útil para uso de la Web creados en base de sistema de herencia. En este método encontramos cinco fases las cuales son: Análisis del entorno, donde el propósito de esta fase es el de estudiar las características de la audiencia, luego encontramos las definiciones de elementos de interés, el análisis del conocimiento y navegación y finalmente la implementación de los análisis realizados.

La propuesta de RNA es quizás una de las que más ha resaltado la necesidad de trabajar con la especificación de requisitos, incluyendo tareas como el análisis del entorno y de los elementos de interés. Además, resulta interesante pues plantea la necesidad de analizar los requisitos conceptuales de manera independiente a los navegacionales.

1.5.1. Fases

A continuación detallaremos cada fase.

1.5.1.1. Fase de Análisis del Entorno

Se determinar y clasifica a los usuarios finales de la aplicación en grupos según sus perfiles

1.5.1.2. Fase de Definición de Elementos

Aquí prosiguen los elementos de interés en la cual se han listando dichos elementos de la aplicación. Por elementos de interés se entienden los documentos, las pantallas que se van a requerir, la información, etc.

1.5.1.3. Fase de Análisis del Conocimiento

Se desarrollar un esquema que represente a la aplicación. Para ello RNA propone identificar los objetos, los procesos y las operaciones que se van a poder realizar en la aplicación, así como las relaciones que se producen entre estos elementos

1.5.1.4. Fase de Análisis de Navegación

Se verifica que el esquema obtenido en la fase anterior sea enriquecido con las posibilidades de navegación dentro de la aplicación

1.5.1.5. Fase de Implementación del Análisis

Cuando una vez obtenido el esquema final en el que ya se encuentran incluidos los aspectos de navegación, se pasa el esquema a un lenguaje entendible por la máquina

2.1. ¿El por qué de una Metodología de Desarrollo Web?

Los principales problemas que nos encontramos es la falta de fiabilidad, seguridad, escalabilidad, mantenimiento, integración y la alta dependencia para su desarrollo e implantación junto con la falta de estándares.

Lo que deseamos es controlar el caos que han provocado en el pasado procesos creativos de desarrollo con el fin de proporcionar un proceso sistemático orientado a la mejora de la calidad de la aplicación final. En esta nueva disciplina se parte de la base de que las necesidades de evolución, mantenimiento, la adaptación a nuevos dispositivos de acceso y la migración a nuevas plataformas y entornos de desarrollo deben dirigir el proceso del ciclo de vida.

Para todo esto se han desarrollado metodologías que permiten estructurar comunicar, entender, simplificar y formalizar tanto el dominio como las decisiones de diseño, así como disponer de Documentación detallada para posibles cambios del software.

2.2. Evolución de las metodologías de Desarrollo Web.

Las distintas metodologías se pueden dividir en tres generaciones en base a su sofisticación, estas son:

2.1.1. Primera Generación

(Principios de los 90) Se sientan las bases de la ingeniería Web, en los que se incluyen conceptos como construcción de navegación, separación entre estructuras y el contenido durante el ciclo de desarrollo.

2.1.2. Segunda Generación

(Segunda mitad de los 90) Se refinan los primeros modelos y se añaden los soportes de funcionalidad básica y se llevan a cabo los primeros esbozos de proceso donde se delimitan los modelos conceptual, lógico y físico.

2.1.3. Tercera generación

(A partir del 2000): Se lleva a cabo la profundización en el soporte para la funcionalidad, enfatización de la figura del usuario en los métodos, y se avanza hacia la estandarización de notaciones, procesos y lenguajes de especificación.

2.3. ¿Qué es UWE?

La propuesta de Ingeniería Web basada en UML (UWE (Koch, 2000)) es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado. UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.

Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.

2.4. Principales aspectos.

Los principales de aspectos en los que se fundamenta UWE son los siguientes:

2.1.4. Uso de una notación estándar

Para todos los modelos (UML : Lenguaje de modelado unificado).

2.1.5. Definición de métodos

Definición de los pasos para la construcción de los diferentes modelos.

2.1.6. Especificación de Restricciones

Se recomienda el uso de restricciones escritas (OCL: Lenguaje de restricciones de objetos) para aumentar la exactitud de los modelos.

2.5. Fases del Desarrollo Web.

Por lo que respecta al proceso de autoría de la aplicación, UWE hace un uso exclusivo de estándares reconocidos como UML y el lenguaje de especificación de restricciones asociado OCL. Para simplificar la captura de las necesidades de las aplicaciones web, UWE propone una extensión que se utiliza a lo largo del proceso de autoría. Este proceso de autoría está dividido en cuatro pasos o actividades:

2.5.1. Análisis de Requisitos

Fija los requisitos funcionales de la aplicación Web para reflejarlos en un modelo de casos de uso.

2.5.2. Diseño Conceptual

Materializado en un modelo de dominio, considerando los requisitos reflejados en los casos de uso.

2.5.3. Diseño Navegacional

Lo podemos subdividir en :

1.5.1.6. Modelo del Espacio de Navegacional.

1.5.1.7. Modelo de la Estructura de navegación

Muestra la forma de navegar ante el espacio de navegación.

2.5.4. Diseño de Presentación

Representa las vistas del interfaz del usuario mediante modelos estándares de interacción UML.

3.1. WSDM: Web Site Design Method. 1997

Define el sistema en base a los grupos de usuario.

Su proceso de definición de requisitos tiene por objetivo el detectar los perfiles de usuario mediante dos tareas.

ü Clasificación de usuarios mediante el estudio del entorno.

ü Descripción de los grupos de usuario.

En la actualidad, están trabando en una propuesta de herramienta que permita soportar el proceso de trabajo.

3.2. SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology. 1998

Esta propuesta ofrece un modelo de escenarios propio, denominado SAC, para representar los requisitos.

Para el desarrollo de los mismos hace uso del diagrama de contexto propuesto en los DFD.

En la actualidad ha caído en desuso, principalmente por el uso de los DFD.

Sin embargo tiene algunas variantes propuesta por los mismos autores.

3.3. RNA: Relationship Navigational Analysis. 1998

Plantea una secuencia de pasos en la que separa el tratamiento de diferentes requisitos:

ü Análisis del Entorno

ü Elementos de Interés

ü Análisis del Conocimiento

ü Análisis de la Navegación

ü Implementación del Análisis

Está muy focalizada a un grupo de sistemas: Los sistemas legales y en la actualidad no es muy usada.

3.4. HFPM: Hypermedia Flexible Process Modeling. 1999

HFPM define un proceso detallado que cubre todo el ciclo de vida y que está compuesto por 13 fases.

En la primera de ellas, modelado de requisitos, propone las tareas siguientes:

ü Descripción breve del problema

ü Descripción de los requisitos funcionales

ü Realización del modelo de datos

ü Modelado de la interfaz de usuario

ü Modelado de los requisitos no funcionales

HFPM no está siendo trabajada actualmente, sin embargo, fue la primera en definir ciertos aspectos:

ü Incluye al usuario desde el principio del desarrollo.

ü Introduce el concepto de la separación de aspectos, propuesto para el análisis, ya desde la Ingeniería de Requisitos.

ü Establece la necesidad de definir modelos específicos para el usuario. Aunque no define ninguno.

ü Establece la necesidad de elaborar

3.5. OOHDM: Object Oriented Hypermedia Design Model.

1999

OOHDM es una propuesta ampliamente aceptada para la web.

Inicialmente no proponía la fase de Ingeniería de Requisitos y centraba su

Desarrollo en cuatro etapas.

Sin embargo, en el año 2001 tuvo una propuesta orientada a la ingeniería de requisitos denominada User Interaction Diagrams (UID).

3.6. UWE: UML-Based Web Engineering. 1999

UWE es una propuesta basada en el proceso unificado y UML pero adaptados a la web.

En requisitos separa las fases de captura, definición y validación.

Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.

En la actualidad ha evolucionado hacia el desarrollo MDD y define los conceptos en base a un conjunto de modelos. UWE ha sido ampliamente

Aceptado en los últimos años. Entra las ventajas más importantes de UWE es su uso 100% UML. Ofrece una herramienta denominada ArgoUWE.

3.7. W2000. 2001

Esta propuesta toma como base los conceptos de HDM para ampliar la notación UML y adecuarla a la web. La fase de especificación de requisitos en W2000 hace una separación y un tratamiento diferente de los requisitos funcionales y los de navegación. Utiliza para ello una extensión de los casos de uso de UML.

3.8. UWA: Ubiquituos Web Applications. 2001

El proyecto UWA ha nacido de la colaboración de varios grupos. Su fase de tratamiento de requisitos se basa en los roles de usuario y en ir refinando los requisitos en un proceso iterativo mediante el que se clasifican los objetivos según su carácter.

3.9. NDT: Navigational Development Tecniques. 2004

NDT es un proceso metodológico para especificar, analizar y diseñar sistemas web.

En el tratamiento de requisitos separa la captura, la definición y la validación de requisitos, proponiendo técnicas específicas para cada uno de ellos.

Ofrece además una herramienta, NDT-Tool, que sirve como soporte en la aplicación de sus técnicas.

3.10. DDDP: Design-driven Requirements Elicitation. 2004

Esta propuesta para el tratamiento de requisitos es parte del proceso design-Driven propuestos por Lowe y Ekluind.

Consiste en realizar la captura, la definición y la validación de requisitos durante el proceso de diseño.

El proceso que ofrecen fue definido en base a un exhaustivo análisis de best practices en el desarrollo de aplicaciones comerciales para la web. La mayoría de las propuestas de Ingeniería Web están muy orientadas a las fases de análisis y diseño, pero, en los últimos años cada día son más los grupos que evolucionan hacía los requisitos.

Cada día son más los grupos que incluyen el tratamiento con los usuarios en sus propuestas. Sin embargo, sigue sin haber una nomenclatura común, ni siquiera una delimitación adecuada de qué es requisitos. Una nueva tendencia, MDD, está buscando esta homogeneidad, no solo en requisitos, sino en todo el proceso.

4.1. Introducción a OOHDM

Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y reusabilidad.

Producir aplicaciones en las cuales el usuario pueda aprovechar el potencial del paradigma de la navegación de sitios web, mientras ejecuta transacciones sobre bases de información, es una tarea muy difícil de lograr.

En primer lugar, la navegación posee algunos problemas. Una estructura de navegación robusta es una de las claves del éxito en las aplicaciones hipermedia. Si el usuario entiende dónde puede ir y cómo llegar al lugar deseado, es una buena señal de que la aplicación ha sido bien diseñada. Construir la interfaz de una aplicación web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo unificado. Por un lado, la navegación y el comportamiento funcional de la aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la aplicación, de aquellas relacionadas con el modelo del dominio.

OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro etapas: diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación.

4.1.1. Diseño Conceptual

En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real.

Se usa notación similar a UML (Lenguaje de Modelado Unificado3) y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad Colaboración4). El esquema de las clases consiste en un conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las clases son usadas durante el diseño navegacional para derivar nodos, y las relaciones que son usadas para construir enlaces.

4.1.2. Diseño Navegacional

La primera generación de aplicaciones web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones. Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual.

El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos.

La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros. Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto.

4.1.3. Diseño de Interfaz Abstracta

Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas.

Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado de independencia de la tecnología de interfaz de usuario. El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar. En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia.

El modelo de interfaz ADVs (Vista de Datos Abstracta5) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación.

4.1.4. Implementación

En esta fase, el diseñador debe implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno web, el diseñador debe decidir además qué información debe ser almacenada.

5.1. APRECIACIÓN PERSONAL

ü El avance de Internet y las comunicaciones han provocado en los últimos años el nacimiento de nuevas propuestas metodológicas para la web.

ü Sin embargo, la mayoría de ellas han centrado su trabajo principalmente en las etapas de diseño e implementación.

ü Existen proyectos que por su envergadura y la complejidad de la información que en él se maneja resulta necesario aplicar una metodología pesada pues han demostrado ser efectivas y necesarias en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso.

ü Las metodologías ágiles por su parte están especialmente orientadas para proyectos pequeños y constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.

CONCLUSIONES

Ø En conclusión la metodología SOHDM es una propuesta nueva que cubre en mayor parte todas las fases del proceso de desarrollo, aunque no toma en cuenta la implantación y las pruebas, proponiéndonos un proceso cíclico de tal forma que al realizar una fase se puede regresar a alguna de las anteriores para refinarla y adaptarla mejor.

Ø OOHDM propone un conjunto de tareas que en principio pueden involucrar mayores costos de diseño, pero que a mediano y largo plazo reducen notablemente los tiempos de desarrollo al tener como objetivo principal la reusabilidad de diseño, y así simplificar la evolución y el mantenimiento.

Ø El avance de Internet y las comunicaciones ha provocado en los últimos años el nacimiento de nuevas propuestas metodológicas para la web.

BIBLIOGRAFIA

ü Nora Koch, Andreas Kraus1, Rolf Hennicker , El proceso de creación de UML basada en Ingeniería Web Enfoque.

ü Cristina Cachero Castro, OO-H: Una extensión de los métodos OO para el modelado y generación automática de interfaces hipermedia les.

ü Lee, H. Lee, C. Yoo, C. (1998). Una metodología basada en entornos orientados a objetos para desarrollo de sistemas de información hipermedia.

ü D. Schwabe, G. Rossi (1998). Desarrollo de Aplicaciones Hipermedia con OOHDM. Taller sobre el Proceso de Desarrollo de Hipermedia, Métodos y Modelos, Hypertext'98, Pittsburg, EE.UU.

ü Koch [UWE], N. (2001). Ingeniería de Software para Aplicaciones Hipermedia Adaptativo.

2 comentarios:

Unknown19 de agosto de 2013, 11:09
Muchas gracias estaba buscando información para metodologías de desarrollo web, esta publicación me permitió orientarme un poco y ahora estoy enfocado en UWE gracias.
ResponderEliminar
Respuestas
Unknown12 de septiembre de 2015, 18:34
Hola gracias por la información, una pregunta amigo en la documentación, para la aplicación web, ahí quienes son los usuarios solamente, los que se registran, los que la usan o el mismo sistema también? quienes son los actores del sistema? ojala me de a entender, gracias y Saludos
ResponderEliminar
Respuestas

Añadir comentario

martes, 31 de mayo de 2011

METODOLOGÍAS DE DESARROLLO DE APLICACIONES WEB

1.5.1.6. Modelo del Espacio de Navegacional.

2 comentarios: