238

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

De Modelos de Proceso a Modelos Navegacionales Carlos Solís, José H. Canós, Manuel Llavador, Mª Carmen Penadés

 Resume: -- Muchos métodos de desarrollo de hipermedia basan la construcción del modelo navegacional en elementos de modelos estructurales, sin tener en cuenta aspectos dinámicos, que igualmente influyen en la navegación. Aproximaciones recientes incorporan aspectos dinámicos tras la generación de un modelo navegacional basado en la estructura. En este trabajo mostramos cómo obtener modelos navegacionales a partir de modelos de proceso lleva a modelos navegacionales más realistas. Siguiendo una aproximación dirigida por modelos y orientada a objetos, definimos las transformaciones de elementos de los modelos de proceso y de clases en elementos del modelo navegacional. Finalmente, ilustramos su aplicación con un ejemplo. Palabras clave: -- Ingeniería Web, navegación, procesos de negocio.

I. INTRODUCCIÓN

L

os métodos de desarrollo de hipermedia aparecidos en la pasada década se han basado en la extensión, más o menos conservativa, de los métodos de desarrollo de software tradicionales. La conjunción de hipertexto y multimedia, por un lado, y la popularización de la Web, por otro, generaron desafíos que los métodos tradicionales no eran capaces, aparentemente, de resolver. Entre ellos destaca el diseño y control de la navegación por espacios complejos de información, que ha llevado a los métodos de la llamada Ingeniería Web a presentar el modelo navegacional como la gran diferencia frente a los métodos tradicionales. Si bien es discutible que la navegación sea exclusiva de la hipermedia o la Web (en cualquier aplicación existe navegación, tal vez no basada en enlaces, pero sí apoyada en otro tipo de elementos de interfaz de usuario), un mérito indiscutible de los métodos de Ingeniería Web ha sido explicitar la necesidad de un diseño cuidadoso de la misma. Sin embargo, la mayor parte de los métodos ha seguido una aproximación basada en la estructura que muchas veces no captura toda la semántica de un problema determinado, ya que se limitan a construir caminos navegacionales derivados de las relaciones estructurales captadas en modelos como el EntidadEste trabajo fue financiado por CICYT España a través de la beca DYNAMICA (TIC 2003-07804-C05-01) y CONACYT México con la beca 178867/193415. Carlos Solís, José Hilario Canós, Manuel Llavador y María del Carmen Penadés son integrantes del Departamento de Sistemas Informáticos y Computación de la Universidad Politécnica de Valencia, Camino de Vera s/n, 46021, Valencia, España. (e-mail: {csolis, jhcanos, mllavador, mpenades}@dsic.upv.es).

Relación, o el Diagrama de clases de UML. Es un hecho reconocido que la naturaleza dinámica de la realidad no queda plasmada en modelos estructurales, sino que son los modelos de proceso los que realmente la capturan. Dicha dimensión ha sido ignorada repetidamente por los métodos de Ingeniería Web, y solo recientemente algunos de ellos han prestado atención a los procesos, aunque de una forma poco natural y siempre como añadido a la generación basada en la estructura del modelo navegacional. En este trabajo mostramos cómo partir de un modelo de proceso es una manera más natural de obtener un modelo navegacional. Tal propuesta se ha plasmado en MDHDM (Model Driven Hypermedia Development Method), un método para el desarrollo de hipermedia que se fundamenta en: por un lado, considerar el proceso como el componente central de una aplicación; por otro lado, utilizar una aproximación dirigida por modelos para establecer un catálogo de transformaciones que permite obtener de forma sistemática los diferentes modelos generados a lo largo del ciclo de vida de una aplicación hipermedia. La principal contribución de MDHDM es, además de la definición de dichas transformaciones, la introducción (a nivel de modelo navegacional) de dos tipos distintos de enlaces: los enlaces de estructura y los de proceso. Tal distinción permite una guía metodológica clara para el desarrollo de aplicaciones hipermedia en las que tanto los procesos como la estructura de la información aportan información para la generación de código final en base a transformaciones de modelos. El resto del documento está estructurado como sigue: En la sección 2 justificamos la necesidad del modelo navegacional en el diseño de aplicaciones hipermedia, se explican sus componentes estructurales y de proceso, y cómo se han usado en otros métodos. En la sección 3 se describe cómo se deriva en MDHDM el modelo navegacional del modelo de proceso y del estructural. Para ilustrarlo en la sección 4 se muestra un ejemplo de un proceso de comercio electrónico. La sección 5 concluye el trabajo. II. LA IMPORTANCIA DEL MODELO NAVEGACIONAL Los métodos de desarrollo de hipermedia proponen estructurar el proceso de desarrollo en una serie de fases. Diferentes métodos incluyen distintas etapas, pero un análisis de todos ellos muestra que siempre están presentes, con uno u otro nombre y en este orden, las siguientes: modelado conceptual, diseño navegacional, diseño de la presentación e implementación.

SOLÍS et al.: FROM PROCESS MODELS TO NAVIGATIONAL

El modelado conceptual tiene como objetivo obtener un modelo del dominio del problema; en algunos métodos (como OOHDM [1] y UWE [2]) el modelo es orientado a objetos, y en otros (HDM [3], RMM [4] y WebML [5]) el modelo es relacional. En el diseño navegacional se obtiene un modelo navegacional a partir del modelo conceptual usando heurísticas. El modelo navegacional es comúnmente definido como una vista del modelo conceptual que refleja la información accesible a un usuario, y los caminos y estructuras de acceso para llegar a ella [1]. El diseño de la presentación trata de la construcción de la interfaz que muestran los elementos navegacionales al usuario, y se efectúa mediante interfaces abstractas de usuario. Finalmente, la implementación es el proceso de codificación del modelo navegacional y la interfaz, y es dependiente de la tecnología. Navigable Class



Tour

Task View

Redirect

Group

Index

1

Menu

?

Query Form

Navigable Associations (Structural links) Process Link

Fig. 1. Elementos del modelo navegacional.

El modelo navegacional es el que marca la diferencia más importante entre los métodos clásicos de desarrollo de software y los de hipermedia. Los elementos del modelo navegacional (ver figura 1) son las clases navegacionales, las asociaciones navegables, y diversas estructuras de acceso, tales como índices y visitas guiadas o tours. Una clase navegacional es una vista de una o más clases del modelo conceptual. Una asociación navegable es un vínculo entre clases navegacionales, y corresponde a lo que en hipermedia se conoce como un hiperenlace. Las estructuras de acceso son elementos que permiten la visualización y acceso a colecciones de clases navegacionales. Una visita guiada permite acceder a la colección de forma secuencial y avanzar hacia delante y atrás entre nodos vecinos. Un índice muestra todos los nodos de su colección y permite el acceso directo a cualquiera de ellos. Un formulario permite el ingreso de datos de entrada que sirven para seleccionar las colecciones de índices y visitas guiadas condicionales. Un menú es una colección de enlaces que, a diferencia de los índices, es estática. En la mayoría de los métodos de diseño de hipermedia el modelo navegacional se deriva del modelo conceptual aplicando unas heurísticas que describimos, sucintamente, a continuación. Las clases navegacionales son consideradas vistas de las conceptuales. Las asociaciones 1-1 se transforman en asociaciones navegables con cardinalidad 1-1. Las asociaciones 1-N se transforman en una estructura de acceso entre dos clases navegacionales; cuando la cardinalidad es pequeña se prefieren visitas guiadas, y en caso contrario son preferibles los índices [4]. Por último, las

239

asociaciones M-N se tratan como dos relaciones 1-N. Si bien esta estrategia puede ser útil en algunos casos, partir sólo del modelo conceptual lleva a un modelo navegacional muy limitado, que no responde a la complejidad de los modelos navegacionales de aplicaciones reales. Considérese, por ejemplo, el portal de una librería electrónica tal como Amazon (http://www.amazon.com). La figura 2 muestra una captura de pantalla correspondiente a una fase intermedia del proceso de compra de un libro. Si bien algunos enlaces corresponden, claramente, a navegación derivada del modelo conceptual (por ejemplo, los enlaces que conducen al detalle de un libro, el menú principal y el botón de envío del formulario de búsqueda), hay otros que de ningún modo tienen ese origen, sino que aparecen en esa pantalla por el hecho de que el usuario, en ese momento del proceso de compra, debe realizar una serie de acciones (indicados por las flechas). En el ejemplo, el usuario está en la actividad de selección: puede añadir un nuevo producto o, como ya ha seleccionado algunos productos, puede editar el carro de compras, o cerrar la compra. En otras palabras: en general existe un proceso de negocio subyacente, cuyo conjunto de tareas y el orden entre las mismas dan lugar a una parte muy importante de la navegación de la aplicación Web. Pese a ello, solo recientemente algunos de los métodos mencionados ha tenido en consideración la perspectiva de proceso en la obtención del modelo navegacional. WebML [5] y OOHDM [1] han sido extendidos para incorporar elementos de proceso en sus primitivas de diseño navegacional. Las primitivas de WebML para modelar flujos de trabajo incluyen bifurcaciones, inicio y fin de actividades, e inicio y fin de procesos. En OOHDM el modelado de procesos se efectúa mediante enlaces etiquetados. Los nodos de hipermedia se separan en nodos de proceso y nodos navegacionales, de modo que si hay un enlace entre un nodo navegacional y un nodo de proceso, entonces éste puede ser etiquetado como inicio o continuación de una instancia del proceso; por su parte, un enlace desde un nodo de proceso a un nodo navegacional puede ser etiquetado como de cancelación, suspensión, o de finalización normal del proceso; finalmente, el estado del proceso está controlado por un contexto, que además indica cuándo los enlaces etiquetados deben ser mostrados. Ambos métodos distinguen entre la navegación sobre el modelo conceptual y la navegación basada en el proceso que se ven como excluyentes. Esta visión, sin embargo, es poco realista: en general, en toda aplicación hipermedia la navegación se efectúa durante la ejecución de alguna tarea, es decir, inclusive la navegación sobre el modelo conceptual debe ser vista como parte de un proceso. En UWE [2] se sigue una aproximación algo distinta, aunque el proceso tampoco es visto como la columna vertebral del sistema. Se parte del análisis de Casos de Uso, los cuales son divididos en navegacionales y de proceso, de aquellos se obtienen clases navegacionales y de éstos clases de proceso, responsables de mantener el estado del proceso. El flujo de control se modela con diagramas de actividad de UML. En

240

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

Figura 2. Librería electrónica.

UWE un enlace entre un nodo navegacional y una clase de proceso es llamado enlace de proceso. En las metodologías existentes el modelo de proceso es introducido durante el diseño navegacional, por lo cual, el modelo resultante no refleja el proceso que ejecuta el usuario. Es necesario partir del modelo de proceso para explicitar las tareas que ejecutará el usuario mientras usa el sistema, y distinguir, claramente, la existencia de dos tipos de enlaces: los estructurales y los de proceso. III. DERIVACIÓN DEL MODELO NAVEGACIONAL A continuación mostramos cómo es posible derivar un modelo navegacional completo en el cual la dimensión de proceso se combine de forma natural con la estructura de la información. Para ello, partimos de dos asunciones fundamentales: Una aplicación puede verse como la implementación de un proceso, consistente en la realización de una serie de tareas para las cuales un usuario debe manejar una determinada información. La sucesión de tareas dará lugar a una sucesión de nodos navegacionales de modo que cada nodo incluirá toda la información que un usuario necesite para realizar la tarea en curso. En cualquier nodo navegacional puede haber dos tipos diferentes de enlace: enlaces de proceso y enlaces estructurales. Un enlace de proceso es aquél que al ser recorrido provoca un cambio en el estado del proceso, es decir, el paso de una actividad a la siguiente. Por su parte, un enlace estructural es el que no provoca avance en el proceso, y suele corresponder a la navegación que un usuario realiza por una estructura de información. En la figura 2, el enlace “Proceed to checkout” (esquina inferior derecha) es un enlace de proceso, pues hace pasar al proceso de la actividad de selección a la de finalización de compra, mientras que cualquiera de los enlaces correspondientes a los títulos de libros llevan a obtener más información sobre los mismos,

pero el proceso no cambia de actividad. Antes de entrar en detalle, presentamos las notaciones que utiliza MDHDM para describir modelos navegacionales y procesos de negocio. A. Modelo navegacional El modelo navegacional usado en MDHDM es similar al de UWE [2], e incluye algunas extensiones a los elementos presentados en la sección 2 (ver figura 1): grupos, que representan colecciones de elementos de hipermedia que comparten caminos navegacionales; redirecciones, que permiten una navegación condicional; vistas de tarea o task views, que representan vistas hipermedia de actividades del proceso, y que son una especialización de las clases navegacionales; y enlaces de proceso, que hacen avanzar el estado del proceso. B. Modelo de proceso de negocio Un modelo de proceso de negocio representa una vista abstracta del trabajo efectuado en una organización para alcanzar un objetivo dado; la llamada Business Process Modeling Notation (BPMN) [6] es el estándar del Object Management Group para la especificación de procesos de negocio, y es la que utiliza MDHDM para representar los modelos de proceso (ver figura 3).

Fig. 3. Elementos del proceso de negocio.

SOLÍS et al.: FROM PROCESS MODELS TO NAVIGATIONAL

241

C ancel S e le ct S e le c t a B o o k V ie w S h o p p in g C a rt

Buy

C h eck S h o p p in g C a rt

Add

Buy

C h eckO ut

Book O id

Fig. 4. Proceso de comercio electrónico. Select a Product

name Enter title

Search Books

Book List

AddBook Show BookList

Book Oid View getBook

Book showBook Buy

Fig. 5. Subproceso de seleccionar productos.

Una actividad (Task) es una unidad de trabajo indivisible, puede ser manual o automática y está asignada a un actor. El flujo de control (Flow) define el orden de ejecución de las actividades, e incluye tareas de bifurcación y sincronización. Un Xor-gateway sirve para representar bifurcaciones y sincronizaciones parciales. Una bifurcación parcial es una tarea que toma una decisión y sólo ejecuta la actividad que está relacionada con el camino donde la condición es verdadera. Una sincronización parcial es un punto en el flujo de control donde la siguiente actividad es ejecutada si alguno de los caminos de entrada ha finalizado. Un And-gateway representa a las bifurcaciones y sincronizaciones totales. Las bifurcaciones totales son tareas que habilitan a todas las actividades que les suceden. Una sincronización total es una tarea que habilita a la siguiente actividad hasta que todos los caminos entrantes han finalizado. El evento Start indica la primera actividad del proceso y el evento End la última. Un subproceso es una tarea compuesta y tiene la misma estructura que un proceso de negocio completo. Los eventos intermedios son usados para modelar aquellos caminos disponibles en cualquier nodo de un subproceso, y que son habilitados por deseo del usuario. Es decir, sirven para modelar bifurcaciones parciales pospuestas (deferred or-split). Para cada decisión y evento intermedio en el proceso se deben identificar las condiciones que los habilitan y que se definen mediante expresiones booleanas usando las propiedades del proceso. C. Flujo de datos El modelo de proceso de negocio define, también, un flujo de datos. Los datos se asocian al flujo de control y son de dos tipos: las propiedades del proceso, llamadas también variables, y los objetos dato. Las propiedades del proceso son datos globales que permiten compartir información entre tareas, y que son regularmente empleadas en la ejecución de decisiones. Por su parte, los objetos dato son la información requerida por una tarea para poder ejecutarse. La BPMN se limita a indicar que tanto las propiedades del proceso como los objetos dato tienen atributos. Los atributos los hemos

clasificado en: tipos de datos simples, referencias a otros objetos dato y compuestos, que agrupan a varios objetos dato. D. Correspondencias Objeto dato. Los objetos dato son equivalentes a clases navegacionales, si tanto la clase navegacional como el objeto dato son reflejo de una clase del modelo conceptual. Las referencias del objeto dato corresponden a asociaciones, y si se trata de un objeto dato compuesto, entonces se obtiene una asociación por composición y otra clase navegacional. Un objeto dato puede ser obtenido también mediante una visita guiada o mediante formularios de captura de datos. Las colecciones de objetos dato son proporcionadas por n ítems de un índice. Actividades manuales. Cada actividad manual corresponde a una vista de tarea. Hay cuatro tipos de ellas: • Actividad de captura de datos, representada por un formulario de entrada de datos. • Actividad de selección, definida como la navegación sobre el modelo conceptual para elegir un objeto dato o una colección de objetos dato de un tipo específico. Las actividades de selección pueden contener opcionalmente un formulario de búsqueda. • Actividad de edición/visualización, que permite editar y/o visualizar una variable de proceso o un objeto dato, y se transforma en una vista de tarea con una composición hacia la clase navegacional correspondiente a la variable de proceso u objeto dato. • Actividad compuesta, que puede dividirse en actividades simples a las que se aplican las correspondencias anteriores. Tareas automáticas. Las tareas automáticas no tienen una correspondencia con ningún elemento del modelo navegacional. En general, se ejecutan cuando el usuario selecciona un enlace de proceso. Bifurcaciones parciales. Las bifurcaciones parciales son transformadas en elementos de redirección si son automáticas, mientras que se transforman en un menú de enlaces de proceso si son manuales.

242

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

Bifurcaciones totales. Las bifurcaciones totales son transformadas en el evento de crear una nueva ventana de navegación, de modo que el usuario realice varias navegaciones en paralelo. Esto no se refleja en los modelos CheckOut

NOk

Ok

hay algunas actividades automáticas implícitas, como buscar producto y obtener un producto. La actividad añadir producto es automática y habilita el subproceso Check-Out. La revisión de carro de compras y la compra puede ocurrir en cualquier

GetPayment&Address Address& Payment Data

Login&Password Login New

User Attributes

RecordUserData

Confirm RecordPayment &Address

BuyDone

Buy

GetUserData ChangeUserData

ChangePayment &Addres

Cancel

Fig. 6. Subproceso de cerrar la compra.

navegacionales. Sincronizaciones parciales y totales. Las sincronizaciones no tienen una correspondencia en el modelo navegacional, ya que corresponden a la reunión de hilos diferentes que desaparecen y cuyos caminos se conectan al nodo de salida. Las sincronizaciones totales unen n flujos de navegación, y corresponden al evento de cerrar una o varias ventanas. Enlaces de proceso. Los enlaces de proceso se derivan de los enlaces restantes del modelo de proceso, es decir, sin contar los eliminados en las sincronizaciones. Los enlaces de proceso se habilitan si el proceso está en el estado donde existen y además el nodo de hipermedia es equivalente al objeto dato requerido como entrada por la siguiente actividad. Subprocesos/ Eventos intermedios. Los subprocesos corresponden a grupos en el modelo navegacional. Sus elementos internos se transforman de modo individual y comparten enlaces de proceso que son derivados de los eventos intermedios del subproceso. Después de aplicar las correspondencias, el modelo navegacional final se obtiene mediante la unión del modelo derivado del proceso con el derivado del modelo conceptual. La semántica de algunos enlaces estructurales puede ser redefinida como de proceso si hay un camino con enlaces de proceso entre los mismos nodos.

momento, por lo que son modeladas como eventos intermedios. El subproceso de revisión del carro de compras empieza mostrando su contenido. El usuario puede modificar la cantidad de cualquier producto seleccionado o vaciar el carro de compras. Para finalizar el subproceso, el usuario puede decidir entre continuar seleccionando productos o proceder a comprar. El subproceso de cerrar la compra (ver figura 6) inicialmente requiere que el usuario provea un nombre de usuario y una contraseña. Si no es un usuario registrado, entonces debe proporcionar sus datos (por ejemplo, nombre, dirección, correo-e, etc.) A continuación, el usuario debe seleccionar la dirección de envío (o indicar una nueva, caso de tener ninguna registrada), y proporcionar información sobre el medio de pago escogido. Como siguiente paso el usuario debe confirmar los datos del pedido; en ese momento, se le debe mostrar el carro de compras y el precio total de la compra; después de la confirmación, se le debe otorgar un número de pedido. El usuario puede cancelar la compra en cualquier paso del proceso, excepto después de haber confirmado el pedido. El modelo conceptual de la librería electrónica se muestra en la figura 7. Author

*

IV. EJEMPLO El proceso que se usa como ejemplo corresponde a la venta de un libro en un entorno de comercio electrónico como el de la Figura 2. El proceso se compone de tres subprocesos: Seleccionar un libro (Select a book), Revisar carro de compras (Check Shopping Cart) y Cerrar la compra (Check-Out) (ver figura 4). El subproceso de selección de un libro (ver figura 5) tiene como objetivo la obtención de un objeto dato que representa un libro. El usuario indica parte del nombre de un libro, tras lo cual el sistema devuelve una lista de libros que satisfacen la consulta; el libro seleccionado se puede añadir al carro de compras, o también, antes de ello, puede solicitarle más información del producto. El usuario puede requerir revisar su carro de compras en cualquiera de las actividades del subproceso, al igual que cerrar la compra si el carro de compras contiene al menos un producto. Además de las actividades mencionadas en la descripción del subproceso,

* Book

Item

* 1

* 1

0..1

* 1

Order

*

Review

1 User

*

* *

1

1

ShoppingCart

Address 1

1 1

1 *

CreditCard

Fig. 7. Modelo Conceptual de la librería electrónica.

Un libro puede ser escrito por n autores, y cuenta con una revisión; además, puede estar contenido en varios carros de compras. Una orden está asociada a un carro de compras, un usuario, una dirección de envío y una tarjeta de crédito. Las

SOLÍS et al.: FROM PROCESS MODELS TO NAVIGATIONAL

243

Figura 8. Modelo navegacional derivado del modelo de proceso de negocio.

direcciones y las tarjetas de crédito pertenecen a un sólo usuario y éste puede tener varias. A continuación describimos las correspondencias usadas para generar el modelo navegacional de la figura 8; con el fin de mejorar la legibilidad del mismo, los pasos efectuados están numerados sobre la misma. El subproceso de selección de un libro corresponde a un conjunto de nodos navegacionales, es decir, un grupo (1) donde aquellos que pueden proporcionar un objeto dato de tipo libro tendrán un enlace de proceso para añadirlos al carro de compras. El grupo de selección también muestra enlaces de proceso para cerrar la compra y editar el carro de compras. La búsqueda se efectúa mediante un formulario (2), que lleva a un índice de libros. Desde el índice de libros o desde la clase navegacional libro se puede agregar un libro al carro de compras (3). El carro de compras es un variable de proceso, y la tarea de edición y visualización del carro de compras se transformó en un nodo que permite editar su contenido (4), que tiene los siguientes enlaces de proceso: uno para vaciar el carro de compras, otro para modificarlo, otro para continuar seleccionando libros, y otro para cerrar la compra. El subproceso de cerrar la compra corresponde a un grupo de nodos (5) que comparten el enlace de proceso de cancelación. La tarea de registro se transforma en un formulario (6), que está conectado a un nodo de redirección (7). Éste se deriva de un Xor-gateway automático, el cual redirige la navegación al nodo de registro si los datos fueron incorrectos, o al nodo de captura de la dirección de envío y de la tarjeta de crédito en caso contrario. La actividad de captura de la dirección de envío y de la tarjeta de crédito es una tarea compuesta (8) que permite la obtención de un objeto dato desde un formulario, o desde la lista de selección de las

direcciones y tarjetas de crédito usadas anteriormente. La tarea de confirmación (9) permite la visualización de la variable de proceso carro de compras. Todos los nodos del subproceso de cerrar la compra muestran el enlace de proceso de cancelación, excepto el nodo que muestra la orden generada (10) al confirmar la compra. Por su parte, las clases y asociaciones del modelo conceptual, de la figura 7, se reflejan en el modelo navegacional, de la figura 8, de acuerdo a las correspondencias mencionadas previamente. V. CONCLUSIONES Y TRABAJO FUTURO El modelo de proceso de negocio es fundamental para capturar la dinámica de los problemas reales. En este artículo hemos mostrado cómo obtener un modelo navegacional a partir de un modelo de proceso de negocio, al que se incorpora la información de navegación derivada de los modelos estructurales. La importancia de este enfoque radica en que la navegación es guiada principalmente por el proceso que efectúa el usuario, y no por las relaciones estructurales del modelo conceptual. Se han mostrado de forma detallada las correspondencias entre los elementos del modelo de proceso y el modelo navegacional, teniendo en cuenta el flujo de control y el flujo de datos. Nuestro trabajo futuro es finalizar una herramienta (actualmente en desarrollo) que de soporte al método, y que nos permita generar aplicaciones dentro del marco de Model Driven Architecture. VI. REFERENCES [1]

H.A. Schmid, G. Rossi, “Modeling and Designing Processes in ECommerce Applications”, IEEE Internet Computing, Vol. 8(1), pp. 1927, (2004).

244 [2] [3]

[4]

[5] [6]

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007 N. Koch, et.al., “Integration of Business Processes in Web Application Models”, Journal of Web Engineering, Vol. 3(1), pp.22-49. 2004. F. Garzotto, P. Paolini, and D. Schwabe, “HDM - A Model-Based Approach to Hypertext Application Design”, ACM Transactions on Information Systems, Vol. 11(1), pp. 1-26. 1993. T. Isakowitz, E.A., Stohr, P.Balasubramanian, “RMM: A Methodology for Structured Hypermedia Design”, Communications of ACM, Vol. 38(8), pp. 34-44. 1995. M. Brambilla, et.al., “Specification and Design of Workflow-Driven Hypertexts”, Journal of Web Engineering. Vol. 1(2), pp.163-182. 2003. Business Process Modeling Notation. OMG Standard Version 1.0. 2006.

VII. BIOGRAFÍAS Carlos Solís es ingeniero en Computación por el Instituto Tecnológico Autónomo de México. Fue analista de sistemas en el Banco de México, donde se especializó en sistemas financieros (SWIFT, Bloomberg, Reuters). Como consultor, ha sido arquitecto J2EE en proyectos para Infonavit, General Motors México, etc. Actualmente, es doctorando en la Universidad Politécnica de Valencia, y su actividad investigadora se enfoca en Ingeniería del software, hipermedia, y sistemas de procesos de negocio. José H. Canós es licenciado en Ciencias Físicas por la Universidad de Valencia, y doctor en Informática por la Universidad Politécnica de Valencia. En la actualidad es profesor titular de universidad en el Departamento de Sistemas Informáticos y Computación, donde enseña Ingeniería del Software y Bibliotecas Digitales. Su labor investigadora se centra actualmente en Bibliotecas Digitales, e Ingeniería del software, además de los sistemas de gestión de emergencias. Manuel Llavador es Ingeniero Informático por la Universidad Politécnica de Valencia. En la actualidad es doctorando en el programa de Programación Declarativa e Ingeniería de la Programación del Departamento de Sistemas Informáticos y Computación de la misma universidad. Su labor investigadora se centra en las áreas de Bibliotecas Digitales e Ingeniería del software y en especial en los sistemas de gestión de emergencias.

Mª Carmen Penadés es licenciada en Informática por la Universidad Politécnica de Valencia, y doctora en Informática por la misma Universidad. En la actualidad es profesora Titular de Escuela Universitaria en el Departamento de Sistemas Informáticos y Computación, donde enseña Ingeniería del Software y Proceso del Software. Su labor investigadora se centra actualmente en Ingeniería del software, Sistemas de Flujo de Trabajo, además de los Sistemas de Gestión de Emergencias.