Generación de Aplicaciones Web Basadas en Procesos de Negocio Mediante Transformación de Modelos

Transcripción

1 IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY Generación de Aplicaciones Web Basadas en Procesos de Negocio Mediante Transformación de Modelos Victoria Torres, Investigador, Universidad Politécnica de Valencia, Vicente Pelechano, Profesor Titular de Universidad, Universidad Politécnica de Valencia, y Pau Giner, Investigador, Universidad Politécnica de Valencia Resumen-- Las aplicaciones Web están evolucionando hacia un entorno inter-organizacional donde aparecen nuevos requisitos (integración de aplicaciones mediante la composición de procesos de negocio de diferentes organizaciones) que deben abordarse en el proceso de desarrollo de aplicaciones. En este trabajo se propone una extensión al método de ingeniería Web OOWS para el desarrollo de aplicaciones Web basadas en procesos de negocio. En esta extensión se ha tenido en cuenta tanto la existencia de tareas manuales llevadas a cabo por participantes humanos como el hecho de que en un contexto B2B los procesos normalmente involucran el uso de funcionalidad distribuida, normalmente proporcionada a través de Servicios Web. Mediante la aplicación del estándar QVT para la transformación de modelos obtenemos a partir de una especificación de proceso de negocio tanto (1) las interfaces gráficas que permiten la ejecución de los procesos como (2) la especificación ejecutable del proceso en WS-BPEL. Palabras clave Programación automática, Modelaje, Ingenieria de software. I I. INTRODUCCIÓN NTERNET se ha convertido en la plataforma más común para el desarrollo de aplicaciones, tanto intra como inter organizacionales. Para dar soporte a la generación de este tipo de aplicaciones emergieron los métodos de ingeniería Web, cuyo principal objetivo era dar soporte a aquellos aspectos que los métodos de desarrollo de software convencionales no consideraban durante la generación de aplicaciones Web. Estos aspectos se refieren principalmente a la navegación y la presentación, los cuales pasaron a ser elementos de primer orden en el proceso de modelado conceptual. Sin embargo, en algunos casos, la descripción de las aplicaciones Web a desarrollar está fuertemente ligada a la definición de procesos de negocio 1 (PN). La especificación de este tipo de Este trabajo ha sido desarrollado con el soporte del MEC bajo el proyecto DESTINO TIN y cofinanciado por FEDER. V. Torres, Universidad Politécnica de Valencia, Camí de Vera s/n Valencia, España ( vtorres@dsic.upv.es). V. Pelechano, Universidad Politécnica de Valencia, Camí de Vera s/n Valencia, España ( pele@dsic.upv.es). P. Giner, Universidad Politécnica de Valencia, Camí de Vera s/n Valencia, España ( pginer@dsic.upv.es). 1 entendiendo también los PN como procesos a largo plazo que permanecen interrumpidos mientras están a la espera de algún estímulo externo o de la interacción con una persona, y donde cada tarea del proceso se ejecuta de forma transaccional. aplicaciones es más compleja que la de aplicaciones Web centradas puramente en datos y requiere, para llevar a cabo la interacción con participantes humanos, de unos interfaces de usuario más elaborados que los proporcionados por sistemas de workflow convencionales. En este contexto, se necesitan métodos que permitan la definición de este tipo de aplicaciones a nivel de modelado (mediante el uso de diagramas de actividades o similares), y que a partir de estas especificaciones, y tras la aplicación de una serie de transformaciones, se obtenga la solución software equivalente. En particular, los métodos de ingeniería Web deberían adaptarse y cubrir la generación de este tipo de sistemas que soportan la ejecución de PN. Esta propuesta ha sido desarrollada en el contexto de OOWS [2] (la extensión Web del método de producción de software orientado a objetos OO-Method [5]), el cual introduce la expresividad necesaria para capturar los requisitos navegacionales y de presentación de las aplicaciones Web. En este trabajo se ha definido una extensión al modelo navegacional (MN) de OOWS que permite modelar los interfaces gráficos que son necesarios para permitir la interacción entre participantes humanos y los PN. Además, esta extensión implica no sólo la introducción de nuevos mecanismos a nivel de modelado, sino que también requiere de nuevos elementos (tales como un motor de procesos y un gestor de tareas) en la arquitectura de las aplicaciones generadas. La contribución de este trabajo es proporcionar una metodología para la generación automática de aplicaciones Web que den soporte a la ejecución de PNs. Para conseguir este objetivo proponemos generar de forma automática a partir de una especificación de PN (1) los interfaces de usuario básicos 2 que permita a los usuarios llevar a cabo las actividades que forman parte del proceso así como (2) la definición ejecutable equivalente del PN en el lenguaje WS- BPEL[9]. En este trabajo se ha tenido en cuenta dos características que se observan en los PN reales, (1) que los PN no sólo incluyen actividades que se van a llevar a cabo de forma automatizada (existirán tareas manuales donde el usuario sólo deberá notificar al sistema la finalización de la tarea) y (2) que las tareas pueden llevarse a cabo por 2 estos pueden enriquecerse manualmente proporcionando información complementaria que ayude al usuario en la realización de las actividades

2 246 IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007 participantes externos a nuestro sistema. El resto del artículo está organizado como sigue. La sección 2 presenta un breve resumen de los trabajos relacionados, tanto en el área de ingeniería Web como en el de motores de procesos. La sección 3 presenta una visión general de la propuesta presentada en este trabajo. La sección 4 introduce el ejemplo que se ha utilizado para presentar la propuesta y los estereotipos añadidos a la notación de BPMN [8] para permitir modelar las correspondientes interfaces gráficas. La sección 5 presenta la extensión que se ha realizado en el MN de OOWS para dar soporte a los PN así como las transformaciones que se han diseñado para obtener el correspondiente MN. Finalmente, la sección 6 presenta las conclusiones así como los futuros trabajos. II. TRABAJOS RELACIONADOS En el área de la ingeniería Web, diferentes propuestas han sido extendidas para dar soporte a la integración entre procesos de negocio y aplicaciones Web [1][3][4][6]. En estos trabajos quedaba patente el hecho de que los métodos de ingeniería Web no eran lo suficientemente expresivos como para dar soporte al modelado de este tipo de aplicaciones. Sin embargo, pese a estas extensiones, estas propuestas comparten algunas de las carencias tales como (1) la integración de aplicaciones, puesto que este es uno de los requisitos que se observan en un contexto inter-organizacional, (2) el desarrollo de interfaces de usuario que guíen a éste en la realización de las tareas que tiene pendientes o (3) la existencia, en procesos de negocio reales, de tareas manuales. Por otra parte, en el área de sistemas de gestión de workflow, existen diferentes propuestas (Oracle BPEL Process Manager, Active BPEL, etc.) que proporcionan una capa de interfaz sobre los motores de proceso para manipular dichos sistemas. Sin embargo, este tipo de soluciones presenta limitaciones en cuanto a la definición de las interfaces a nivel de modelado y por lo tanto, cualquier modificación que se desee realizar deberá realizarse a nivel de implementación. III. VISIÓN GENERAL DE LA PROPUESTA La mayoría de métodos de ingeniería Web siguen un enfoque dirigido por modelos, los cuales cubren aspectos como la estructura, comportamiento, navegación y presentación necesarios para especificar una aplicación Web. ESPACIO DEL PROBLEMA ESPACIO DE LA SOLUCIÓN OO-Method Modelo Estructural «usa» Modelo de Procesos de Negocio «genera» Transf. Modelo-a-Texto Definición ejecutable del PN (WS-BPEL) Fig. 1 Visión general de la propuesta «genera» Transf. Modelo-a-Modelo «usa» OOWS Modelo Navegacional Modelo de Servicios «genera» Transf. Modelo-a-Texto Capa de Presentación Interfaces Web (asp, php, jsp, etc.) La Fig. 1 presenta una visión general de los modelos involucrados en la propuesta así como de las relaciones definidas entre ellos. La especificación del conjunto de procesos de negocio que deben soportar las aplicaciones se realizan a nivel del espacio del problema en el Modelo de Procesos de Negocio (MPN). El objetivo del MPN es describir mediante una notación gráfica la secuencia de tareas que deben realizar los diferentes participantes. Las tareas que conforman los procesos pueden ser de dos tipos, automatizadas (cuya realización supone la ejecución de cierta funcionalidad por parte de un sistema) o manuales (tareas que no están automatizadas en ningún sistema). Las tareas automatizadas implican la invocación de operaciones modeladas bien en el Diagrama de Clases (DC) o bien en el Modelo de Servicios (MS). Las relaciones entre el MPN, el DC y el MS se muestran gráficamente en la Fig. 1 mediante una flecha estereotipada con la palabra clave <<usa>>. El conjunto de operaciones definido en el DC representa la funcionalidad proporcionada dentro de los límites de nuestro sistema. Por otro lado, la funcionalidad que es importada de sistemas externos está definida en el MS. El MS fue introducido en un trabajo previo [7] para definir los servicios (y las operaciones proporcionadas por estos) proporcionados por sistemas externos. Las ventajas que introduce definir la funcionalidad externa a nivel de modelado son (1) que permite tratar la funcionalidad como si formase parte de nuestro propio sistema, facilitando la integración entre la funcionalidad externa y el resto de modelos definidos en el método y (2) permite tener representaciones abstractas y genéricas de la funcionalidad proporcionada por diferentes proveedores, evitando los problemas tanto tecnológicos como semánticos que puedan darse. Algunas de las tareas definidas en el proceso requieren de una interfaz de usuario para ser realizadas. Las interfaces de usuario se definen en el MN y permiten al usuario interactuar con el proceso introduciendo datos, iniciando otras tareas o tomando decisiones sobre cierta información mantenida en el sistema. La relación entre el MPN y el MN se muestra en la Fig. 1 mediante una flecha con el estereotipo <<genera>> Transformación Modelo-a-Modelo. Esta flecha indica que a partir de la definición del PN, y tras aplicar un conjunto de transformaciones, se obtiene la parte del MN que dará soporte a la ejecución de los procesos. Posteriormente, una vez definido completamente el MN, y tras la aplicación de una nueva transformación, en este caso de modelo a texto, se obtienen las interfaces de usuario representadas en una tecnología concreta. Finalmente, para ejecutar los PN en un motor de procesos, transformamos la definición del proceso a un lenguaje de procesos ejecutable. Esta transformación queda representada en la Fig. 1 mediante una flecha con el estereotipo <<genera>> Transformación Modelo-a-Texto. Una vez obtenida la descripción ejecutable equivalente podemos ejecutar el proceso en cualquier motor que soporte la ejecución de procesos especificados en WS-BPEL.

3 TORRES et al.: GENERATION OF BUSINESS PROCESS 247 IV. EL MODELO DE PROCESO DE NEGOCIO Con el fin de ilustrar la propuesta, se ha incluido en este trabajo un ejemplo basado en un escenario real identificado en el Departamento de Sistemas y Computación de la Universidad Politécnica de Valencia. El departamento ha desarrollado una aplicación Web ( siguiendo la aproximación OOWS. Esta aplicación proporciona la información y funcionalidad típica de gestión organizacional de un departamento (acceso a directorios personales, información de las asignaturas impartidas por el departamento, inscripción a seminarios, etc.). Además, esta aplicación da soporte implícito (a través de la navegación) a una serie de PNs. Sin embargo, las actividades que conforman los PNs permanecen ocultas en la navegación de la aplicación, y los usuarios perciben las operaciones de forma individual y no como parte de un proceso completo. Esto puede provocar que usuarios involucrados en el proceso se pierdan al realizar una actividad (especialmente si se trata de un proceso que se extiende en el tiempo). El PN que se ha tomado como ejemplo (Solicitud de compra de libros) tiene como objetivo realizar la compra de un libro para la biblioteca del departamento y realizar el préstamo al solicitante una vez el libro llega al departamento. Este proceso supone la participación de varios agentes, desde personas (personal de secretaría, bibliotecario del departamento y el miembro solicitante) hasta sistemas automáticos (los sistemas de la biblioteca general y del propio departamento). La Fig. 2 muestra la especificación del proceso utilizando la notación de BPMN. DSIC SISTEMA BIBLIOTECARIO SECRETARIA MIEMBRO «entity» «role-any» «role-any» «role-one» BIBLIOTECA CENTRAL «entity» «user» Solicitar compra libro Petición [pendiente] «user» Validar la solicitud Petición [validada] Aprobar? No Default (Si) Notificar rechazo petición «send» Enviar solicitud «receive» Recepción notif. compra «manual» Recoger libro Cargar detalles de libro + Fig. 2 Definición del proceso Solicitud de Compra de Libros Notificar compra de libro Prestar libro Puesto que sólo vamos generar la parte del proceso que concierne a nuestro sistema (DSIC), la figura sólo incluye la especificación de las actividades del DSIC así como de los mensajes intercambiados con el sistema externo. Para diferenciar cuando un participante humano toma parte en el proceso como individuo o como miembro de un colectivo hemos especializado el tipo de participante role (tipo que representa a participantes humanos) en role-one (para individuos) y role-any (para colectivos). Cuando especificamos un participante como role-one exigimos que sea el mismo usuario el que realice todas las tareas asignadas a la calle (lane) a la que pertenece. Por otro lado, las tareas que no se han definido como manual tendrán siempre asociada una operación (o un conjunto de operaciones) a invocar. Estas operaciones se refieren a las definidas bien en el DC o bien en el MS. Estas extensiones se han realizado a nivel de metamodelo, ampliando el metamodelo BPMN con los atributos indicados. V. TRANSFORMACIONES MODELO-A-MODELO: DE BPMN A OOWS Esta sección se divide en tres subsecciones. En la primera se presentan las primitivas añadidas al modelo de navegación y en las dos siguientes se presentan las reglas de transformación que se han definido para generar los MNs de OOWS a partir de la especificación de un PN en BPMN. A. Nuevas Primitivas de OOWS para dar Soporte a Procesos de Negocio Actualmente, el método OOWS permite a los usuarios decidir qué camino, de los definidos en el mapa navegacional, seguir para explorar el sistema (a través de enlaces de exploración o de secuencia). Sin embargo, durante la ejecución de un proceso, el usuario no decide los contextos por los que navegar, sino que es el propio proceso el que guía al usuario para la realización de cierta tarea. Por esta razón, se han incluido las primitivas necesarias que permiten modelar los contextos navegacionales involucrados en los procesos para distinguirlos de los Contextos Navegacionales tradicionales. Las primitivas introducidas son: ProcessContext, ActivityContainer, Main-AIU, Complementary-AIU y Human-AIU. Dado un tipo concreto de usuario, la primitiva ProcessContext define el conjunto de actividades asignadas a dicho usuario para un mismo proceso. Cada una de estas actividades se representa mediante la primitiva ActivityContainer. Un ActivityContainer está formado por un conjunto de AIUs. Un AIU (Abstract Information Unit) es un mecanismo de abstracción introducido para agrupar un conjunto de contenidos (vistas de clases) que poseen cierta relación semántica. La primitiva AIU permite modelar los contextos como una agregación de contenidos, donde no es necesaria relación alguna entre AIUs. En esta extensión se han introducido tres tipos de AIUs: Main-AIU, Complementary-AIU y Human-AIU. Un ActivityContainer se define como un conjunto de AIUs, los cuales pueden incluir un Main-AIU o un Human-AIU y opcionalmente varios Complementary-AIU necesarios para realizar cierta actividad. La primitiva Main-AIU presenta los datos y funcionalidad necesaria para realizar la actividad para la cual se diseñó. La primitiva Human-AIU proporciona al usuario un mecanismo para notificar al proceso de que se ha completado una actividad manual (una tarea que no ha sido automatizada en el sistema). La interfaz gráfica que implementa un Human-AIU incluye la descripción de la tarea manual a realizar (por ejemplo: Enviar un documento por fax o Celebrar la reunión y hacer los preparativos correspondientes ). Por el contrario, los Complementary-AIU proporcionan información que complementa la proporcionada en un Main-AIU o en un Human-AIU. Aunque el contenido proporcionado por un Complementary-AIU no es vital para completar la actividad, ayuda al usuario a realizarla (por ejemplo: una lista de elementos necesarios para tomar una decisión, evitando que el usuario tenga que navegar a través del sistema para localizar dicha información).

4 248 IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007 B. Definición de Reglas de Transformación La definición de las reglas de transformación sólo tiene en cuenta las tareas que involucran la participación de personas (tareas del tipo manual y user). A continuación se muestra de forma intuitiva las transformaciones que se han definido entre los modelos de BPMN y de OOWS: ProcessContext: Por cada calle (lane) definida como role (one o any) se creará un ProcessContext con el mismo nombre. El rol usado en la definición del PN deberá corresponderse con alguno de los tipos de usuario definido en el Diagrama de Usuarios. En el ejemplo usado se crea un ProcessContext llamado Solicitud Compra Libro para el tipo de usuario secretaría (ver Figura 3). ActivityContainer: Por cada tarea con intervención humana (tipo manual o user) incluida en una calle (lane) de tipo role (one o any), se creará un ActivityContainer con el mismo nombre. En el ejemplo se observa que el ProcessContext Solicitud Compra Libro, creado anteriormente, incluye dos ActivityContainers: Validar Solicitud y Recoger Libros. AIU: En función del tipo de tarea se generará un tipo de AIU. o Para tareas de tipo user, se incluirá un Main-AIU en el ActivityContainer correspondiente. Si la operación asociada a la tarea pertenece al Diagrama de Clases, se incluirá en el Main-AIU una vista de la clase que contenga la operación. Si la operación definida en la tarea se corresponde con una operación modelada como Servicio (en el MS), se incluirá una vista del servicio correspondiente en el Main-AIU. o Para cada tarea de tipo manual se creará un Human-AIU en el ActivityContainer correspondiente. La Fig. 3 incluye el Human- AIU Recoger libro definido en el correspondiente ActivityContainer. Tras aplicar estas transformaciones se obtendrá el MN básico para ejecutar el proceso. La Fig. 3 muestra el ProcessContext obtenido para el rol secretaría así como la página Web que lo implementa. Este ProcessContext incluye además un conjunto de información complementaria que se ha añadido manualmente como (1) un índice asociado al Main-AIU Validar Solicitud y (2) dos Complementary-AIUs asociados al ActivityContainer Validar Solicitud. El índice definido para el Main-AIU Validar Solicitud proporciona acceso indexado a la población de la clase Libro_solicitado. Este índice recupera una lista desde la que el usuario podrá seleccionar un elemento (objeto). Esta selección activa el objeto en el AIU. Por otro lado, los Complementary-AIUs añadidos al ActivityContainer proporcionan al usuario dos listas que muestran los miembros sancionados y las últimas adquisiciones. Estas listas proporcionan la suficiente información para que el usuario responsable de esa tarea tenga la información necesaria para decidir sobre la aceptación o no de cada solicitud, evitando que ésta tenga que buscarse navegando por la aplicación. P «activity container» Validar Solicitud «Main-AUI» Validar Solicitud Libro_solicitado -titulo -autores Miembro -editorial -nombre -num_edition -apellidos -anyo_publicacion -unidades_a_comprar +resolver_solicitud() estado = pendiente or rechazada INDEX RB_by titulo ATTRIBUTES titulo, Miembro.nombre, Miembro.apellidos OPERATION validar_solicitud() LINK ATTRIBUTE titulo «activity container» Recoger Libros «Human-AUI» Recoger Libros SECRETARIA CAMBIAR PERFIL HOME Departmento Directorio Docencia Investigación Intranet Procesos Enlaces Procesos Sol. Compra Libros Sol. Compra Equipam. Miembro solicitante Juan García Pérez María Sánchez Ortiz María Sánchez Ortiz «process context» Solicitud Compra Libro Miembros sancionados María Sánchez Ortiz Raúl Pérez Sanz Pedro Solaz Bueno Joaquín Bermúdez Gracia Rosa López Reina Juan A. Moreno Marques «Complementary-AUI» Ultimas Adquisiciones Copia Libro -titulo Ultimas_adquisiciones «Complementary-AUI» Miembros Sancionados Miembro -nombre -apellidos sancionado = true Título Software Engineering Software Engineering Web Ontologies Validar Solicitud Aceptar Procesos Rechazar Aceptar Información Complementaria Últimas adquisiciones Software Engineering Programming Java Programming Web Services in.net Algorithms Quality on Software Engineering Datawarehouse and XML Fig. 3 ProcessContext y página Web para el proceso "Solicitud Compra Libros" y el rol secretaría C. Implementación y Organización de las Transformaciones Las transformaciones desarrolladas en este trabajo se han definido utilizando el lenguaje imperativo Operational Mappings de MOF 2.0 QVT [10]. Este lenguaje permite definir transformaciones unidireccionales entre modelos los cuales son instanciaciones de los metamodelos definidos siguiendo la especificación MOF (Meta Object Facility). Como herramienta hemos utilizado Borland Together Architect 2006 for Eclipse que permite definir transformaciones definidas en este lenguaje y ejecutarlas sobre modelos definidos mediante Ecore (implementación de MOF Core y base del Eclipse Modeling Framework). Para llevar a cabo la transformación entre el modelo de BPMN y el de OOWS, se ha implementado un conjunto de reglas de transformación cuyas dependencias se muestran gráficamente en la Fig. 4. Además de estas reglas de transformación, se ha definido un conjunto de consultas que se van a usar en varias reglas y que nos permiten obtener información a cerca de los modelos. main lane2userrole task2activitycontainer Attribute2 NavigationalAttribute Fig. 4 Relación de dependencia entre las reglas task2mainaiu task2humanaiu

5 TORRES et al.: GENERATION OF BUSINESS PROCESS 249 Se ha definido una transformación inicial (main) a partir de la cual se invocan las diferentes transformaciones que permiten la generación del correspondiente modelo OOWS. Esta transformación toma como entrada un modelo que sigue nuestro metamodelo de BPMN extendido e invoca la primera transformación (process2navigationmodel) que se encarga de transformar el proceso en el correspondiente MN. mapping main(in model: bpmnx::bpm): oows::oowsmodel { object { ClassDiagram:=model.ClassDiagram; NavigationalModel:= process2navigationalmodel(model.process); La transformación process2navigationalmodel se encarga de generar el MN a partir de la definición de proceso. El MN incluirá un UserRol (primitiva de OOWS que representa a un usuario) generado mediante la transformación lane2userrole. Esta se aplicará únicamente a calles (lanes) que representen participantes del proceso que necesiten interactuar con éste a través de interfaces gráficas. Esta transformación hace uso de las consultas needsui y ismain para determinar qué calles (lanes) requieren de interfaz gráfico y qué parte del proceso hace referencia a nuestro sistema. Por ejemplo, la consulta needsui nos indica, a partir de una definición de proceso BPMNX, si los elementos lane definidos en el modelo requieren de una interfaz gráfica para participar en el proceso. Como muestra la siguiente porción de código, estos elementos tendrán asociado un interfaz gráfico cuando se trate de lanes que incluyan tareas definidas como user o como manual. query bpmnx::lane::needsui():boolean{ self.tasks()->select(t t.needsui())->notempty(); query bpmnx::task::needsui():boolean{ let tipos_validos= Set{ bpmnx::tasktype::user, bpmnx::tasktype::manual in tipos_validos->includes(self.type); También se han definido sobre los elementos lane, las consultas tasks y events que permiten obtener respectivamente el conjunto de tareas y eventos incluidos en dicho lane. La transformación task2activitycontainer se aplica a todas las tareas incluidas en los lanes del pool principal. A continuación se muestra la implementación: mapping task2activitycontainer(task:bpmnx::task): oows::activitycontainer when{ task.needsui(){ init{ var mainaiu:= task2mainaiu(task).oclastype(oows::baseaiu); var humanaiu:= task2humanaiu(task).oclastype(oows::baseaiu); var aiu:= if (mainaiu->notempty()) then mainaiu else humanaiu endif; object{ name:=task.name; BaseAIU:=aiu; Esta transformación se aplica sólo a las tareas que requieren de interfaces gráficas. Esta condición se indica en la cláusula when de la regla. Los ActivityContainer han sido definidos para incluir sólo una AIU de tipo Main o Human, siendo en la sección init de la regla donde se obtiene la AIU adecuada. El objeto creado (sección object) será un ActivityContainer con el nombre de la tarea y la AIU obtenida. La generación de los diferentes tipos de AIUs se lleva a cabo mediante la aplicación de las transformaciones task2humanaiu y task2mainaiu que se explican a continuación. La transformación task2humanaiu, a partir de una tarea de tipo manual, genera una Human-AIU que representará una actividad que no está automatizada en el sistema. Este tipo de AIU no incluye más información, y todo lo que se desee añadir (por ejemplo para facilitar la tarea al usuario) deberá realizarse de forma manual a través de nuevas Complementary-AIU. Por otro lado, la transformación task2mainaiu se aplica sobre tareas de tipo user. A continuación se muestra su implementación: mapping task2mainaiu(task:bpmnx::task): oows::mainaiu when { task.type = bpmnx::tasktype::user{ init { var operacion:=task.assignation.operation; object{ name:=task.name; ManagerClass:=object oows::managerclass { Class:=operacion.Class; NavigationalOperation:= (object oows::navigationaloperation{ name:=operacion.name; Operation:=operacion; )->asorderedset(); NavigationalAttribute:= operacion.class.attribute->collect (a attribute2navigationalattribute(a)) ->asorderedset(); ; El objeto Main-AIU generado tendrá el mismo nombre que la tarea y se creará un objeto de tipo ManagerClass que representa una vista sobre una clase del DC. Esta clase será la clase propietaria de la operación (task.assignation.operation) asignada a la tarea en la definición del proceso. La vista sobre la operación (NavigationalOperation) se creará indicando la operación y su nombre. Todos los atributos de la clase se añadirán directamente a la vista de la clase convirtiéndolos en atributos de la vista (navegationaattribute).

6 250 IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007 Tras la aplicación de estas transformaciones se obtiene el correspondiente MN de OOWS a partir de un modelo de proceso de negocio. Este modelo de OOWS incluye los elementos necesarios para generar el interfaz de la aplicación Web que dará soporte a la ejecución del correspondiente proceso de negocio. VI. CONCLUSIONES En este trabajo se ha presentado una solución basada en la transformación de modelos para generar aplicaciones Web cuya especificación está fuertemente ligada a una descripción de proceso de negocio. Como trabajos futuros se ha planificado integrar la solución presentada en este trabajo en la herramienta ONME. Esta herramienta proporciona un entorno basado en el modelado conceptual donde los modelos representan el programa, y el proceso de generación de código está totalmente automatizado siguiendo la estrategia MDA. Además, se ha planteado estudiar los patrones de presentación asociados a las nuevas primitivas introducidas en el modelo de navegación. De hecho, el modelo de presentación está basado en el MN y utiliza los contextos de éste para definir las propiedades de presentación. VII. REFERENCIAS Artículos Publicados en Conferencias: [1] De Troyer, O., Casteleyn, S.: Modeling Complex Processes for Web Applications using WSDM, In Proceedings of the Third International Workshop on Web-Oriented Software Technologies, IWWOST2003 [2] Fons, J, Pelechano, V., Albert, M., Pastor, O.: Development of Web Applications from Web Enhanced Conceptual Schemas. In Workshop on Conceptual Modeling and the Web, ER'03, volume 2813 of Lecture Notes in Computer Science. Springer, [3] Manolescu, I., Brambilla, M., Ceri, S., Comai, S., & Fraternali, P. (2005). Model-driven design and deployment of service-enabled web applications. ACM Trans. Inter. Tech. 5, 3, [4] N. Koch, A. Kraus, C. Cachero and S. Meliá, Integration of Business Processes in Web Application Models. Journal of Web Engineering. Vol. 3, No. 1 (2004) [5] Pastor, O., Gomez, J., Insfran, E. and Pelechano, V. The OO-Method Approach for Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems 26, pp (2001) [6] Schmid, H. A., Rossi, G.: Modeling and Designing Processes in E- Commerce Applications. IEEE Internet Computing 8(1): (2004) [7] Torres, V., Pelechano, V., Ruiz, M. and Valderas, P., A Model Driven Approach for the Integration of External Functionality in Web Applications. The Travel Agency System. MDWE VIII. BIOGRAFÍAS Victoria Torres es estudiante de doctorado en el Departamento de Sistemas Informáticos y Computación (DSIC) en la Universidad Politécnica de Valencia, España. Sus intereses de investigación son la ingeniería Web, los procesos de Negocio, modelado conceptual y desarrollo dirigido por modelos. Es miembro del grupo de investigación OO-Method y ha publicado varias contribuciones en conferencias internacionales. Su trabajo de tesis consiste en el desarrollo de aplicaciones Web dirigidas por Procesos de Negocio. Vicente Pelechano es Titular de Universidad en el Departamento de Sistemas Informáticos y Computación (DSIC) de la Universidad Politécnica de Valencia. Sus intereses de investigación abarcan ingeniería web, modelado conceptual, ingeniería de requisitos, patrones software, servicios web, sistemas pervasivos y desarrollo dirigido por modelos. Obtuvo el título de Doctor por la Universidad Politécnica de Valencia en Actualmente imparte clases de ingeniería del software, desarrollo dirigido por modelos, diseño e implementación de servicios web y patrones de diseño en la Universidad Politécnica de Valencia. Es miembro del Grupo de Investigación de Producción Automática de Software OO-Method. Ha publicado artículos en revistas científicas de reconocido prestigio (Information Systems, Data & Knowledge Engineering, Information and Software Technology, International Journal of Web Engineering and Technology, etc.), capítulos de libro en Springer y el grupo IDEA y ha sido invitado en numerosas conferencias internacionales (ER, CAiSE, WWW, ICWE, EC-WEB, WISE, AH, ICSOC, DEXA, etc.) Es miembro del Comité Científico de reconocidas Conferencias Internacionales y Workshops como CAiSE, ICWE, ICEIS, ACM MT y IADIS. Pau Giner es estudiante de doctorado en el Departamento de Sistemas Informáticos y Computación de la Universidad Politécnica de Valencia (UPV). Obtuvo el título de Ingeniero Informático en la facultad de Informática de la UPV. Sus intereses de investigación se centran en el desarrollo de software dirigido por modelos y en la construcción de sistemas ubicuos a partir de Procesos de Negocio. Ha participado en el "International Collegiate Programing Contest" organizado por la Association for Computing Machinery (ACM) y en el programa MIT-UPV Exchange. Es miembro del Grupo de Investigación de Producción Automática de Software OO-Method. Estándares: [8] Business Process Modeling Notation (BPMN) Version May 3, 2004 [9] Business Process Execution Language for Web Services Specification, version 1.1 dated May 5, 2003 [10] Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Final Adopted Specification ptc/