Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos

Transcripción

1 Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos Maximiliano Vanzetti CIDISI, Universidad Tecnológica acional-frsf, Lavaisse 610, 3000, Santa Fe, Argentina Abstract Los nuevos modelos de gestión alientan a las empresas a establecer relaciones de colaboración con sus socios a través de soluciones B2B. Esto requiere la elaboración de modelos y especificaciones de los procesos de negocio colaborativos que definen el comportamiento entre las empresas. A fin de proporcionar un entorno que permita el desarrollo de soluciones B2B, se propuso una herramienta que explota los principios de la Arquitectura Dirigida por Modelos para el modelado, verificación y especificación de Procesos de egocio Colaborativos. Entre sus funcionalidades, la herramienta propone la aplicación de una máquina de transformación de modelos necesaria para la generación de especificaciones de Redes de Petri que permita verificar la correctitud de los modelos. Actualmente, existen numerosas herramientas de transformación de modelos y seleccionar la más apropiada no es una tarea trivial. Por este motivo, el objetivo de este trabajo es llevar a cabo una evaluación empírica y una comparación de las herramientas de transformación de modelos más relevantes. Esta evaluación permite fundamentar la selección de la herramienta de transformación de modelos más apropiada para ser utilizada en el desarrollo de Procesos de egocio Colaborativos, y además resulta de suma utilidad para llevar a cabo una adecuada implementación de la máquina de transformación de modelos. Palabras Clave Transformación de Modelos, Arquitectura Manejada por Modelos, Procesos de Negocio Colaborativos, Redes de Petri 1. Introducción Existe una marcada tendencia entre las empresas en formar relaciones de colaboración B2B con sus clientes y proveedores, para lograr disminuir los costos y mejorar los beneficios en la gestión de la cadena de suministro. La definición explícita y detallada de un modelo de colaboración se formaliza en los Procesos de Negocio Colaborativos. Estos procesos respetan los lineamientos generales del modelo de colaboración y no sólo determinan la información a ser intercambiada, sino también el comportamiento que tendrán las interacciones entre los socios y las responsabilidades de cada uno en dicho proceso. De esta forma las empresas pueden tomar decisiones en forma conjunta para alcanzar metas comunes, coordinar sus acciones e intercambiar información. Por lo tanto, el diseño de los procesos colaborativos es un objetivo clave para las empresas que participan en una colaboración B2B. En [8], se propuso un método basado en Arquitectura Manejada por Modelos (Model Driven Archetecture - MDA) para el modelado y especificación de procesos de negocio colaborativos independientemente del uso de las tecnologías. Este método explota los beneficios de MDA para dar soporte a las diferentes etapas del desarrollo de colaboraciones B2B, de procesos colaborativos y de los sistemas que soportan la ejecución de los mismos. Para el diseño de procesos colaborativos, este método propone el uso del lenguaje UML Profile for Collaborative Business Processes based on Interaction Protocols (UP-ColBPIP). La base teórica del lenguaje está sustentada por el uso del formalismo de protocolos de interacción para representar procesos colaborativos [8]. A través de la definición de protocolos de interacción, los diseñadores se enfocan en modelar no sólo el intercambio de información, sino también los aspectos de comunicación requeridos en los procesos colaborativos, tales como negociaciones y la creación de compromisos entre las partes. En el diseño de procesos colaborativos, la verificación de los modelos de estos procesos es de suma importancia para garantizar el correcto funcionamiento de la colaboración entre empresas [8]. Para llevar a cabo la verificación de las propiedades de

2 los modelos de procesos colaborativos, tales como la ausencia de bloqueos (deadlocks), ciclos infinitos (livelocks), o la comprobación de que ciertos estados de un proceso son alcanzables, es necesaria la formalización de dichos modelos. Para ello se propuso un enfoque de verificación [10], el cual utiliza Redes de Petri Coloreadas (CP-Nets) y Jerárquicas [1] para formalizar protocolos de interacción definidos con el lenguaje UP-ColBPIP. Luego estas Redes de Petri pueden ser utilizadas para verificar ciertas propiedades y determinar si un modelo de proceso colaborativo está correctamente definido. En [5, 6], se presentó una versión prototipo de un ambiente de desarrollo integrado (IDE), basado en la plataforma Eclipse [12], que da soporte a este método MDA para procesos colaborativos y al lenguaje UP- ColBPIP. En [12], se incorporaron nuevos elementos al lenguaje y la semántica de otros fue modificada. La adición de estos elementos al IDE es un requerimiento importante para dar un completo soporte al modelado y verificación de procesos colaborativos. En particular, para dar soporte a este enfoque de verificación de procesos colaborativos, se requiere la incorporación de máquinas de transformación de modelos al IDE basado en Eclipse, que permitan generar las especificaciones de Redes de Petri que representan los modelos de procesos colaborativos definidos con el lenguaje UP-ColBPIP. Por este motivo, el objetivo de este trabajo es presentar una evaluación empírica y una comparación de las herramientas de transformación de modelos más relevantes que permitan generar especificaciones en Redes de Petri a partir de modelos UP-ColBPIP. Esta evaluación permite fundamentar la selección de la herramienta de transformación de modelos más apropiada, y además resulta de suma utilidad para llevar a cabo una adecuada implementación de la máquina de transformación de modelos. En la sección 2 se presenta el enfoque MDA para Procesos de Negocio Colaborativos. En la sección 3 se describen las herramientas de transformación. En la sección 4 se evalúan las herramientas estudiadas. En las secciones 5 y 6 se establece una discusión y se presentan las conclusiones respectivamente. 2. Enfoque MDA para Procesos de egocios Colaborativos Los modelos de procesos colaborativos definidos en el nivel de negocio o solución de negocio son una parte clave en el desarrollo de colaboraciones B2B, y debido a la necesidad de poder generar en forma automática a partir de estos modelos las especificaciones B2B de los procesos, se considera al Desarrollo Dirigido por Modelos (Model Driven Development - MDD) como una práctica de diseño adecuada para ser explotada en un método que soporte todas las etapas del desarrollo de procesos colaborativos [8]. En MDD, los modelos son considerados los conductores primarios en todos los aspectos del desarrollo de software. Una de las principales ventajas que tiene el proceso de desarrollo dirigido por modelos es la independencia tecnológica. Además de los modelos, el otro componente fundamental de MDD son las transformaciones. El proceso de transformar una especificación de software en un programa ejecutable tiene que ser automático. El código fuente de las aplicaciones se genera a partir de los modelos en un proceso de transformación, del mismo modo que el código máquina se genera a partir del código fuente escrito en un lenguaje de alto nivel en un compilador tradicional. MDD es un enfoque de desarrollo de software basado en modelos y en la generación de la aplicación a partir de éstos. Solo proporciona una estrategia general a seguir en el desarrollo de software pero no define ni técnicas, fase del proceso, ni ninguna guía metodológica [3]. Como parte de este esfuerzo para incrementar la aceptación del enfoque MDD, la OMG creó una serie de estándares de soporte a MDD a los cuales agrupo en las especificaciones de MDA. Así MDA es un estándar que promueve a MDD y agrupa a varios lenguajes que pueden ser utilizados para seguir un enfoque dirigido por modelos en una organización, MDA intenta estandarizar MDD, que durante muchos años ha estado a la deriva. El método para el modelado y especificación de procesos colaborativos propuesto en [8] [10] está basado en los principios y componentes de la iniciativa MDA. El mismo posibilita la separación de los conceptos del nivel de negocio, de los del nivel tecnológico, lo cual permite pasar en forma automática desde el dominio del problema (solución de negocio) al dominio de la solución tecnológica. Esto permite incrementar el nivel de reutilización de los modelos de procesos colaborativos, y también posibilita la implementación de procesos colaborativos usando diferentes tipos de tecnologías, permitiendo a los socios de negocio poder elegir entre una mayor variedad de tecnologías de acuerdo a sus requerimientos e intereses. [6] El Método basado en MDA para el desarrollo de procesos colaborativos [8] propone un proceso de desarrollo que consiste de tres etapas, tal como se observa en la Fig. 1. Las etapas del proceso de

3 desarrollo definidas son: análisis y diseño de procesos colaborativos, verificación de procesos de colaboración y generación de especificaciones B2B. Figura 1. Etapas de la metodología MDA para procesos de negocios colaborativos. En la etapa de análisis y diseño de procesos colaborativos, el modelado de procesos se enfoca en los conceptos de negocio de una colaboración B2B, dejando de lado aquellos conceptos ligados a la tecnología de implementación. UP-ColBPIP es un lenguaje de modelado desarrollado en [7], definido como un perfil de UML que permite el modelado de los procesos colaborativos, independientemente de los conceptos tecnológicos. Siguiendo un enfoque topdown, el modelado de los procesos utilizando este lenguaje consta de cuatro fases para modelar las vistas de un modelo de colaboración B2B: Vista de la Colaboración B2B: define los participantes de una colaboración B2B, los parámetros del acuerdo de la colaboración y las metas de negocio comunes a ser alcanzadas por los socios. Vista de los Procesos Colaborativos: identifica los procesos de colaboración necesario para lograr los objetivos de negocio comunes. Vista de los Protocolos de Interacción: define el comportamiento explícito de los procesos de colaboración mediante el uso de protocolos de interacción. Vista de las Interfaces de Negocio: define las interfaces de negocios de los socios, que contienen los servicios (operaciones) que soportan el intercambio de mensajes de los protocolos de interacción. Mediante la vista de los Protocolos de Interacción queda definido el comportamiento de los procesos colaborativos. Un protocolo de interacción describe un modelo de comunicación de alto nivel a través de una secuencia de mensajes entre todos los socios que participan en la colaboración. La secuencia de mensajes representa el flujo de control global de las interacciones punto a punto entre los socios del negocio, así como las responsabilidades de los roles que cumplen. Puesto que los procesos colaborativos describen las conductas de las partes que intervienen en una colaboración B2B es de suma importancia determinar que el comportamiento definido en estos procesos colaborativos sea correcto y que no existirán fallas en la ejecución de los mismos. Es en la segunda etapa donde se lleva a cabo la verificación de los procesos de negocio colaborativos definidos en los modelos UP- ColBPIP. Los protocolos de interacción de un modelo UPColBPIP son transformados en especificaciones de Redes de Petri, de tal manera que las propiedades de los procesos pueden ser verificadas a través de herramientas de Redes de Petri. El método MDA para procesos colaborativos define un patrón de transformaciones de modelos (ver Fig. 2) para la generación automática de especificaciones formales de procesos colaborativos en Redes de Petri. Figura 2. Patrón de Transformaciones para generar especificaciones de Redes de Petri Los modelos de Redes de Petri son definidos de acuerdo al lenguaje PNML (Petri Net Markup Language), que es un lenguaje estándar basado en XML para Redes de Petri.

4 A partir de estos modelos, se generan documentos XML que contienen las especificaciones de Redes de Petri correspondientes a los protocolos de interacción. Una vez generadas las especificaciones de Redes de Petri, mediante el uso de herramientas de análisis de Redes de Petri, se verifican las propiedades de las redes que representan los procesos colaborativos. Finalmente, la tercera etapa consiste en generar las especificaciones de los procesos colaborativos y las interfaces de los sistemas de los socios de negocio, basadas en un estándar B2B que deberá ser acordado por los mismos para satisfacer sus requerimientos tecnológicos. La generación de especificaciones de los procesos colaborativos necesita dos tipos de lenguajes: uno para la especificación de procesos de negocio y el otro para la especificación de las interfaces de los sistemas de los socios. De esta manera, es necesario manipular, transformar y generar modelos de procesos de negocio específicos de la tecnología y modelos de interfaces de sistemas específicos de la tecnología [6]. 3. Herramientas de Transformación La metodología MDA para procesos colaborativos plantea el uso de modelos en el nivel de negocio para la verificación de las propiedades de los procesos en las primeras etapas de desarrollo, en lugar de realizar las verificaciones de los procesos sobre las especificaciones B2B, luego de la generación de la solución tecnológica. La verificación en etapas tempranas del desarrollo de las propiedades de los procesos colaborativos es de gran importancia ya que en esta fase los analistas de negocio y diseñadores de sistemas toman las decisiones más primordiales. En [10] se propone el uso de Redes de Petri Coloreadas y Jerárquicas para formalizar protocolos de interacción definidos con el lenguaje UP-ColBPIP. De esta manera se puede representar claramente la semántica de los protocolos de interacción y verificar las propiedades de los mismos. Se diseñaron un conjunto predefinido de patrones en redes de petri. Cada uno de los patrones formaliza un elemento del lenguaje UP-ColBPIP correspondiente a la vista de los protocolos de interacción. Siguiendo la definición de los patrones, se construyen módulos de CP-Nets que son compuestos en CP-Nets Jerárquicas para representar los protocolos de interacción a ser verificados [6]. La herramienta CPN Tools [14] ha sido usada para definir a estos patrones. La misma provee un método de espaciado de estado para verificar el comportamiento de las redes de petri. Recurriendo a los conocimientos de la teoría de Redes de Petri, los resultados de las verificaciones son interpretados para determinar si una CP-Net, representativa de un protocolo, es correcta y por lo tanto el protocolo está libre de errores. Es por ello la necesidad de contar con una herramienta que permita la transformación de modelos de procesos colaborativos en especificaciones de redes de petri. La transformación de modelos juega un papel clave en el desarrollo dirigido por modelos, puesto que serán un conjunto de transformaciones las que, partiendo de un conjunto de modelos que especifican un sistema, permitan conseguir el software ejecutable sobre una plataforma concreta [2]. Utilizando la terminología de la iniciativa MDA, un proceso de transformación recibe como entrada un conjunto de modelos independientes de la plataforma (PIM) y un conjunto de reglas de transformación. Como producto de un proceso de transformación se obtiene un modelo específico a la plataforma (PSM). Esta estructura se denomina Patrón MDA [4] (Fig. 3). Figura 3. Patrón MDA Se han analizado un conjunto de herramientas de transformación de código abierto basadas en MDA para el desarrollo de una máquina de transformaciones de modelos de procesos colaborativos a Redes de Petri como un plug-in de Eclipse. Las herramientas elegidas en base en base al crecimiento, aceptación y utilización que han tenido en la comunidad MDA fueron: MOFScript, Acceleo, Open Architecture Ware (oaw) y Java Emitter Templates 2 (JET 2). Cada una de ellas son frameworks integrados en la plataforma Eclipse. A continuación se presenta una descripción de cada una de estas herramientas. 3.1 MOFScript MOFScript [16] es un proyecto que tiene como objetivo desarrollar herramientas y frameworks que den soporte a las transformaciones modelo a texto (M2T). El proyecto forma parte del proceso de

5 normalización de la OMG para la RFP del proceso de transformación de modelo a texto. MOFScript es una herramienta de transformación de modelo a texto. Las herramientas de transformación de modelo a texto pueden ser clasificadas en soluciones basadas en plantillas y soluciones basadas en lenguajes. MOFScript forma parte de esta última clasificación. El lenguaje de MOFScript es un lenguaje mixto: es declarativo ya que permite la definición de reglas de transformación, y a su vez es imperativo puesto que ya cuenta con descripciones de reglas de transformaciones y funciones auxiliares. La herramienta admite la entrada de varios modelos para el proceso de transformación. Permite la inserción de metamodelos definidos por el usuario y a su vez cuenta con una librería de metamodelos predefinidos. Para poder usar los metamodelos creados hay que configurar las referencias de la herramienta indicando la ruta donde se encuentran los mismos. MOFScript se instala fácilmente en el entorno de eclipse. Cuenta con mucha documentación en su página oficial y existe variada información en la WEB. Las reglas de transformación son creadas en archivos con extensión.m2t. En la medida que se necesite hacer uso de las transformaciones creadas, se deben importar las mismas, indicándolo en el comienzo de cada uno de estos archivos. Para facilitar el desarrollo de las reglas, MOFScript brinda un Syntax high-lightning en su editor de reglas y una consola que logra una retroalimentación con el programador. Una vez desarrolladas las reglas, deberán ser compiladas. Si existiera algún inconveniente, la consola mostrará los detalles del mismo. Habiendo terminado correctamente la etapa de compilación, la regla definida como principal es ejecutada y el proceso de transformación del modelo se llevará acabo respetando todas las reglas desarrolladas. El archivo resultado de la transformación se alojará en la ruta donde se configuro las preferencias de MOFScript. 3.2 Acceleo Acceleo [13] es una herramienta de transformación de modelo a texto. En base a la clasificación antes hecha sobre este tipo de herramientas, Acceleo es una herramienta con un lenguaje basado en plantillas o templates. Teniendo en cuenta los estándares definidos por EMF, Acceleo brinda un enfoque MDA simple permitiendo la generación de archivos a partir de modelos UML, MOF o EMF. Acceleo cuenta con las siguientes características: Generación de código basada en plantillas que expresan reglas de transformación entre un modelo y el código utilizando una sintaxis similar a JSP. Una completa integración con el ambiente de Eclipse y el framework de EMF. Navegación por los elementos de cualquier modelo que siga los estándares de EMF (XMI). Administración de la sincronización entre el código y el modelo. Generación incremental de código. Simplicidad en el mantenimiento y actualización de todas las plantillas. Coloreado sintáctico de las plantillas así como detección de errores basada en el metamodelo. Previsualización del código. Acceleo permite definir plantillas donde se define el texto a generar de acuerdo a las propiedades encontradas dentro del modelo. Los Templates son almacenados en archivos con extencion.mt. La sintaxis ofrece un conjunto de instrucciones que permiten realizar ciclos, tomar decisiones y navegar por los elementos del modelo. Esto provee una forma de integrar conceptos relativos a una plataforma específica dentro de las plantillas y extraer esos conceptos de los modelos de manera que estas puedan ser independientes de la plataforma. Cuando se hayan desarrolladas todas las plantillas de transformación, se deben crear las cadenas de generación (Generation Chain). Acceleo brinda un asistente para la generación automática de las mismas. Primeramente se debe indicar el metamodelo a ser utilizado. Luego se debe seleccionar el modelo en sí. Acceleo está basado en los principales estándares MDA, lo que garantiza su compatibilidad e interoperabilidad con otras aplicaciones, como GMF. Es compatible con XMI, fue diseñado para trabajar con cualquier metamodelo y permite extender la funcionalidad ofrecida mediante la importación de librerías de Java, que pueden utilizarse para agregar funcionalidad a las plantillas y la generación de código. Una vez seleccionado el metamodelo y el modelo de entrada, se debe indicar las plantillas utilizadas en el proceso de generación. Luego se guarda la cadena indicando su nombre y la ubicación donde se alojará. El proceso de transformación comenzará con la ejecución de una de las cadenas de generación creadas. Esto se logra usando la función Launch sobre la cadena de generación. El archivo producto de la transformación será generado en el formato que se haya indicado y guardado en la dirección establecida.

6 3.3 Open Architecture Ware Open Architecture Ware (OAW) [17] es un framework desarrollado en Java como un plugin de Eclipse de soporte MDA compuesto de diversos módulos que cubren gran parte del proceso de desarrollo. Este framework no sólo cubre las transformaciones modelo a texto sino que es más ambicioso y pretende servir de soporte para el proceso de generación completo. Entre las principales características de esta herramienta encontramos: Procesos de transformación configurables. Transformaciones Model 2 Model (M2M). Transformaciones Model 2 Text (M2T). Transformaciones Text 2 Model (T2M). Comprobación de restricciones de modelo. Aplicación de aspectos a las transformaciones. Es una herramienta que tiene un enfoque hacia los modelos creados en UML2, pero que da soporte total a los modelos desarrollados con EMF. El framework soporta diversos tipos de metamodelos y proporciona un conjunto de lenguajes para validar, transformar y generar código a partir de los mismos. OAW cuenta con un motor de workflow que define el proceso de generación de código. Distintos modelos predefinidos pueden ser indicados en el workflow para luego transformar ellos en otros modelos o transformar los modelos de entradas en código. Para el desarrollo de la máquina de transformación de modelos, es necesario el uso del módulo para generar código (Xpand) que brinda oaw. Para crear un generador de código en oaw en primer lugar se debe definir el archivo de workflow del proceso de generación. Este archivo es almacenado con extensión.oaw. El workflow controla las distintas fases que forman el generador, carga de los modelos, validación de los mismos, generación de código, etc. Además permite configurar el metamodelo en el cual se basa la generación, así como los directorios de destino del código generado. Como se menciona en las características de la herramienta, Open Architecture Ware es una herramienta que permite la transformación de Modelo a Modelo y la transformación de Modelo a Texto. La función de transformación de Modelo a Texto se basa en los dos tipos de soluciones: soluciones basadas en plantillas y soluciones basadas en lenguajes. En el workflow se debe definir el template raíz a partir del cual se inicia el proceso de transformación. Las distintas reglas del compilador se encuentran definidas como plantillas escritas en el lenguaje Xpand de oaw. Cada uno de estos templates son guardados en archivos con extensión.xpt. El lenguaje Xpand también incorpora instrucciones propias de un lenguaje de programación imperativo como bucles o sentencias condicionales. El concepto central del lenguaje Xpand que utiliza oaw es el bloque DEFINE, el cual es la unidad mínima que forma una plantilla. Cada bloque DEFINE específica una regla de transformación de un elemento del metamodelo. El encabezado de un DEFINE se compone de un nombre que lo identifica, un conjunto de parámetros opcionales y el nombre de la clase del metamodelo sobre la cual se define la regla. El cuerpo del bloque DEFINE puede contener otras expresiones del lenguaje o cualquier tipo de texto que se añadirá al proceso de generación. Para diferenciar el código estático a generar de las expresiones e instrucciones de Xpand, estas últimas se delimitan mediante los símbolos << >>. Las expresiones son las encargadas de procesar la información proporcionada por la instanciación del metamodelo. Una vez evaluada la expresión, el resultado es volcado como un String. La generación del código mediante Xpand se basa en la concatenación de llamadas a reglas que van produciendo código para un elemento concreto del metamodelo. Ese proceso comienza en la regla DEFINE definida como raíz en el workflow. Para invocar una regla se utiliza la sentencia EXPAND, que recibe el nombre del bloque DEFINE a expandir junto a los parámetros si este los tuviese. La sentencia EXPAND recibe también un elemento del metamodelo que deber ser del tipo que espera el bloque DEFINE. Como los metamodelos son definidos de una manera estructurada (como es el caso del árbol de metamodelo que impone EMF), es difícil añadir comportamiento adicional como operaciones de consulta o atributos derivados del metamodelo. OAW lo soluciona introduciendo extensiones basadas en el lenguaje Extend. Una extensión es una propiedad definida sobre un elemento del metamodelo de forma externa a éste. A través de las extensiones es posible añadir comportamiento adicional que puede ser reutilizado y que simplifica la definición de las reglas. Las extensiones son archivos con prefijo.ext. Finalizado el proceso de transformación, el código resultante es insertado en un archivo dentro de la ruta indicada en las propiedades del archivo workflow. 3.4 Java Emitter Templates 2 Java Emitter Templates 2 (JET2) [15] es una herramienta de transformación de modelo a texto que hace uso de un lenguaje basado en plantillas. Es una

7 herramienta de código abierto desarrollada como un plug-in de Eclipse que permite generar código a partir de modelos basados en EMF. JET2 es una actualización de Java Emitter Templates y es parte del nuevo proyecto Eclipse Modeling Framework Technology (EMFT). JET2 se diferencia de JET en varios aspectos. JET puede utilizarse fuera de Eclipse, pero no JET2. Se tendrá que crear un plugin de Eclipse que será capaz de manejar la entrada dinámica. Si no se desea crear un plug-in de Eclipse, es conveniente optar por JET. JET2 también difiere de su antecesor en su sintaxis y en el uso de las etiquetas. La herramienta se instala fácilmente, permite como entrada cualquier modelo desarrollado con EMF y los archivos de salida pueden ser de cualquier tipo (txt, java, xml, etc). Figura 4. Proceso de Transformación de JET2 Las plantillas son una mezcla de texto y comandos de JET2 (tags), utilizando una sintaxis similar a JSP para escribir las plantillas que expresaran el código a generar. Cuando se inicia un nuevo proyecto, JET2 automáticamente crea dos plantillas: main y dump. Las plantillas (o templates) son archivos con extensión.jet. La plantilla main es el punto de partida para la transformación invocando a las demás plantillas desarrolladas que serán usadas en el proceso de transformación. La plantilla dump señala a uno o más modelos de entrada para el proceso de transformación. JET2 emplea cuatro librerías de etiquetas: Etiquetas de Control: utilizadas para el acceso al modelo de entrada, y el control de ejecución de la plantilla. Etiquetas de Formato: empleadas para modificar el formato de texto en las plantillas de acuerdo a ciertas reglas. Etiquetas Java: permiten la generación de código Java. Etiquetas workspace: utilizadas para el manejo de recursos del workspace, tales como archivos, carpetas y proyectos. Una vez que se han desarrollado todos los templates y establecido el orden en la plantilla main.jet, se ejecuta el proceso de transformación. La Figura 4 representa este proceso de transformación de JET2. De acuerdo a la dirección de salida establecida, el o los archivos creados con sus respectivos formatos, serán alojados en dicho lugar. 4. Evaluación de las Herramientas de Transformación Con el propósito de poder evaluar las herramientas de transformación estudiadas, se definieron un conjunto de requerimientos que fueron utilizados para analizar y comparar cada una de las herramientas. Los requerimientos definidos son: Tiempo de Aprendizaje: indica el tiempo necesario para el aprendizaje de la herramienta. Facilidad de uso: evalúa que tan fácil es usar la herramienta y que nivel de programación se requiere para hacer uso de la herramienta. Información Disponible: determina la cantidad de información que se encuentra disponible para el aprendizaje y que sirva de ayuda para el proceso de desarrollo. Tiempo de Instalación: indica el tiempo necesario para instalar la herramienta. Tipo de solución: indica si la herramienta de transformación de modelo a texto cuenta con una solución basada en plantillas o una solución basada en lenguajes. Reglas de transformación: determina el soporte que provee la herramienta con respecto a la implementación de las reglas que definen qué bloques de código se generarán para cada elemento en el modelo. Independencia de la Plataforma: evalúa la capacidad de la herramienta de generar cualquier tipo de archivo de salida necesario. Navegación por los elementos del modelo: determina si la herramienta permite acceder a los elementos del modelo en la etapa de desarrollo. En la Tabla 1 se muestran los requerimientos propuestos y el soporte que provee cada herramienta a dichos requerimientos.

8 Tabla 1. Comparación de herramientas de transformación de Modelo a Texto MOFScript Acceleo OAW JET2 Tiempo de Aprendizaje Lento Rápido Medio Rápido Facilidad de uso Compleja Fácil Media Media Información Disponible Mucha Poca Mucha Mucha Tiempo de Instalación Rápido Rápido Medio Rápido Tipo de solución Basado en Lenguaje Basado en Plantillas Basado en Lenguaje/Plantilla Basado en Plantillas Reglas de transformación Lenguaje Restringido Lenguaje Restringido Desarrollo transparente de las reglas Rápida implementación de cualquier tipo de regla Independencia de la Plataforma Navegación por los elementos del modelo Cualquier Tipo de Archivo Cualquier Tipo de Archivo Cualquier Tipo de Archivo Cualquier Tipo de Archivo Simple Simple Media Media 5. Discusión Se han realizado varias pruebas en cada una de las herramientas para aprender a utilizarlas y analizar las características de cada una de ellas. La evaluación principal fue tratar de lograr una transformación M2T, que permita como modelo de entrada un modelo UP-ColBPIP y la salida del proceso de transformación sea un archivo con las especificaciones de Redes de Petri en un formato de archivo de la aplicación CPN-Tools. El lenguaje utilizado por MOFScript cuenta con cierta complejidad por lo que el aprendizaje del mismo no es tan sencillo. MOFScript permite la inclusión de metamodelos definidos por el usuario, sin embargo, no da ayuda para definirlos. Las diferentes pruebas realizadas en la herramienta sobre transformaciones que involucren como modelos de entradas modelos del tipo UP-ColBPIP, han superado las etapas de compilación de las reglas, pero al momento de ejecutar las mismas, el proceso de transformación de MOFScript desconoce la existencia del metamodelo. La máquina de transformación de modelos de procesos colaborativos a redes de petri necesita como modelo de entrada, un modelo UP-ColBPIP. Al no haber cumplido totalmente con este requerimiento fundamental en las pruebas efectuadas, se ha descartado el uso de MOFScript para la implementación de la máquina de transformación de modelos. Acceleo es una solución basada en plantillas. Tiene un lenguaje restringido comparando con otros lenguajes, sin embargo se pueden implementar reglas de transformación de cierta complejidad. Además, de la facilidad de aprendizaje de la sintaxis empleada, Acceleo tiene una gran automatización en sus funciones y no es necesario tener gran conocimiento en lenguajes de programación. Existe gran cantidad de información en el sitio oficial de Acceleo, pero no se encuentran suficientes trabajos en la web que sirvan de ayuda y soporte en la etapa de desarrollo. La herramienta ha superado varias pruebas de transformaciones pero, al igual que con MOFScript, no se ha podido lograr la importación de modelos UP-ColBPIP como modelo de entrada en el proceso de transformación.

9 El lenguaje utilizado por Open Architecture Ware (OAW) para el desarrollo de las reglas de transformación es de fácil aprendizaje. El empleo del archivo workflow permite una clara interpretación del proceso de transformación. El encadenamiento de las reglas se da en forma transparente, fácil de entender y muy práctico a la hora de realizar trabajos de mantenimiento en el código. Una ventaja de OAW es su editor especial del lenguaje Xpand. Esta herramienta de soporte ayuda aun más a la comprensión de las reglas de transformación. La instalación de la herramienta tiene un mayor tiempo que las demás, pero a pesar de esto es sencilla. Existe gran cantidad de información en la web y buena documentación en su página principal. A diferencia de las dos herramientas anteriores, se han podido realizar numerosas pruebas de transformación cuyos modelos de entradas sean modelos del tipo UP- ColBPIP. Como se ha mencionado anteriormente, OAW cuenta con un lenguaje de extensiones, para poder añadir comportamiento adicional en las reglas, como operaciones de consulta o atributos derivados del metamodelo. Es necesario para el proceso de transformación contar con tipos de datos en lenguaje java que den soporte al desarrollo de las reglas. OAW permite en cierta manera hacer uso de los mimos. Sin embargo se debe hacer numerosas replicas de código para poder interactuar con estas clases. Todo lo que OAW gana en el mantenimiento del código de sus reglas, lo pierde en el mantenimiento del código de las extensiones. Debido a la riqueza del lenguaje basado en plantillas utilizado por JET2, cualquier regla de transformación puede ser implementada de manera rápida. El aprendizaje de JET2 es un tanto más complejo que Acceleo (incluso a su antecesor JET), sin embargo no es complicado aprender a utilizar la herramienta. Existe muy buena documentación tanto en su sitio oficial como en el resto de la web. Una desventaja de JET2 es que no cuenta con un editor del lenguaje Xpand y la navegación por los elementos de los modelos creados es una tarea de programación. Sin embargo JET2 permite de manera natural el uso de cualquier tipo de datos diseñados en java para poder añadir comportamiento adicional en las plantillas. El uso de plantillas de JET2 reduce notablemente el tiempo de desarrollo de las transformaciones de modelos a código. Esta característica es una ventaja que tiene JET2 en comparación con las demás herramientas. Todas las pruebas de transformación llevadas a cabo en JET2 han cumplido con los resultados esperados y con un tiempo de implementación inferior al resto de las herramientas. 6. Conclusión En este trabajo se ha llevado a cabo el análisis de un conjunto de herramientas para la transformación de modelos a ser utilizadas en un enfoque MDA para procesos colaborativos. Además se propusieron un conjunto de requerimientos que estas herramientas deben soportar. Estos requerimientos fueron utilizados para llevar a cabo la evaluación y comparación de las herramientas. Después de haber analizado y comparado a cada una de las herramientas de transformación, se ha decidido optar por JET2. El tiempo de implementación de las transformaciones de modelos a código mediante el uso de templates de JET2 es inferior al resto de las herramientas. Se encuentra disponible gran cantidad de documentación acerca de JET2 y el tiempo necesario para aprender a usar la herramienta es mínimo. Debido a la riqueza del lenguaje utilizado por JET2, cualquier regla de transformación puede ser implementada rápidamente y se puede extender de manera natural el comportamiento de las plantillas mediante el empleo de cualquier tipo de dato desarrollado en lenguaje java. 7. Referencias [1] Girault, C., Valk, R. Petri ets for System Engineering: A Guide to Modeling, Verification, and Applications, Springer-Verlag, New York, Inc, 2001 [2] Hebach, M. MDA with QVT. Presentación Borland Together, [3] Muñoz, J., Pelechano, V. MDA vs factorías de software. Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM). España, [4] Object Management Group. Model Driven Architecture (MDA) Guide, Versión [5] Roa, J., Castañeda, V., Villarreal, P., Chiotti, O. A Tool for Model-Driven Development of Collaborative Business Processes. XXXIV Conferencia Latinoamericana de Informática. Santa Fe, Argentina, 2008.

10 [6] Roa, J., Castañeda, V. Ambiente de Desarrollo Integrado para el Modelado y Verificación de Modelos de Procesos de egocio Colaborativos. Proyecto de Grado, Ingeniería Sistemas de Información. Universidad Tecnológica Nacional, Santa Fe, Argentina [7] Villarreal, P., Salomone, E., Chiotti, O. A UML Profile for Modeling Collaborative Business Processes based on Interaction Protocols. Argentine Symposium on Information Systems, 33 JAIIO. Argentina, [8] Villarreal, P. Método para el Modelado y Especificación de Procesos de egocio Colaborativos. Tesis Doctoral. Universidad Tecnológica Nacional, Santa Fe, Argentina, [9] Villarreal, P., Salomone, E, Chiotti, O. Applying Model-Driven Development to Collaborative Business Processes. Proceedings 8º Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software. Valparaiso, Chile, [10] Villarreal, P., Roa, J., Salomone, E, Chiotti, O. Verification of Models in a MDA Approach for Collaborative Business Processes. Proceedings 10th Ibero-American Workshop of Requirements Engineering and Software Environments, Enterprise Modeling and Computing with UML. Idea Group Inc, [12] Villarreal, P., Lazarte, I., Roa, J., Chiotti, O. A Modeling Approach for Collaborative Business Processes based on the UPColBPIP Language. In: 3rd International Workshop on Collaborative Business Processes. LNBIP, vol 43, pp , Ulm, Alemania, Springer, [13] Acceleo, última fecha de consulta 26/JUL/10. [14] CPN tools, última fecha de consulta 26/JUL/10. [15] Java Emitter Templates 2 (JET2), última fecha de consulta 26/JUL/10. [16] MOFScript, última fecha de consulta 26/JUL/10. [17] Open architecture ware, última fecha de consulta 26/JUL/10. [11] Villarreal, P., Salomone, E, Chiotti, O. Modeling and Specifications of Collaborative Business Processes using a MDA Approach and a UML Profile. In: Rittgen, P. (eds):