See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/279852233

BPMN Studio: Fábrica de Software para la modelación y despliegue de Procesos

de Negocios basados en la notación BPMN

Article · March 2015

CITATIONS

0READS

516

2 authors, including:

Some of the authors of this publication are also working on these related projects:

Academic Libraries in Videogames View project

Rendering View project

Miguel Katrib

University of Havana

44 PUBLICATIONS   48 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Miguel Katrib on 07 July 2015.

The user has requested enhancement of the downloaded file.

BPMN Studio: Fábrica de Software para la modelación y despliegue de Procesos de Negocios basados en la notación

BPMN

Octavio Cesar Cuenca de Lamar1, Miguel Katrib Mora1

1 University of Havana octavio@matcom.uh.cu, mkm@matcom.uh.cu

Resumen.

Este artículo propone la creación de una Fábrica de Software llamada BPMN Studio que permite la modelación e integración de procesos de negocios basados en un subconjunto del dominio de definición de BPMN. A partir de un mismo modelo va a ser posible generar los componentes que se encargan de integrar y ejecutar la lógica del proceso modelado en diferentes plataformas de software. Para la transformación del modelo se propone el uso de un tipo de flujo de trabajo llamado Process. El diseño de BPMN Studio se basa en el uso de un DSL gráfico para la modelación de procesos, el cual tiene definido un proceso de transformación en el que el usuario debe escoger un generador entre varios con el propósito de integrar el proceso en una determinada plataforma de software. Su arquitectura altamente extensible va a permitir a sus usuarios personalizar su funcionamiento además de poder agregar nuevos generadores. Los productos generados van a poder ser desplegados de forma automática y sin la asistencia de un programador en la aplicación huésped donde se desean integrar los procesos. Con el objetivo de facilitar esta tarea se proponen dos enfoques prácticos referentes a la arquitectura que deben seguir las aplicaciones involucradas en el proceso de integración.

Palabras clave. BPMN, DSL, Desarrollo de Software Dirigido por Modelos, Workflow, Inyección de Dependencias

1. Introducción

La Gestión de Procesos de Negocios[1] (BPM de Business Process Management) es una metodología corporativa cuyo objetivo es mejorar el desempeño de una organización a través de la gestión de los procesos de negocios, procesos que se deben diseñar, modelar, integrar y optimizar de forma continua. Estos procesos son representados mediante el uso de lenguajes de modelación de procesos (BPLs) de los cuales uno de los más establecidos es Business Process Modeling Notation (BPMN)[2], cuyo objetivo es proporcionar una notación estándar y legible por todos los involucrados en el proceso. BPMN tiene una notación flexible, capaz de representar procesos empresariales complejos en el que se pueden interrelacionar diferentes fuentes de información, como bases de datos, servicios web, ocurrencia de eventos, entre otros

Inicialmente desarrollado por Business Process Management Initiative (BPMI), BPMN es mantenido actualmente por el Object Management Group1 (OMG), luego de la fusión de ambas organizaciones en el año 2005. En el 2011 fue lanzada la versión BPMN 2.0 con una notación aún más completa dirigida a permitir el despliegue y ejecución de los procesos modelados en una aplicación de software. Esto lo convierte en uno de los lenguajes de modelación de procesos con mayor potencial y futuro y ha provocado que importantes empresas han apostado por su uso, y han creado sus propias herramientas para la gestión y manejo de procesos de negocios expresados en esta notación. Esta adopción de una notación común ha ayudado a cerrar la brecha de comunicación que frecuentemente se presenta entre el modelado y diseño de los procesos de negocio por un lado y su implementación concreta sobre una plataforma destino por otro.

Para ejecutar un proceso modelado en BPMN 2.0, la OMG propone hacer una transformación Modelo-

Código. El lenguaje propuesto para llevar a cabo esta traducción es BPEL2 (Business Process Execution Language), lo que presupone que se debe disponer de un motor de ejecución para este lenguaje en el servidor en el que se vayan a hospedar los procesos. Sin embargo, en la práctica no ha sido viable lograr un total cumplimiento de esto y muchas de las plataformas de software dedicadas a la modelación, manejo y ejecución de procesos de negocios basados en BPMN no usan BPEL como lenguaje de ejecución. Apuestan por enfoques propios que transformen el modelo a flujos de trabajo y/o a código en lenguajes de programación de propósito más general. Las plataformas que disponen de esta posibilidad son conocidas como Sistemas de Gestión de Procesos de Negocios (BPMS, Business Process Management System) [3].

Este artículo propone una solución computacional que pretende lograr los mismos propósitos de un

BPMS pero con un enfoque diferente en cuanto a la manera en que se despliegan y manejan los procesos. La idea es seleccionar un subconjunto del dominio de definición de BPMN suficiente para poder modelar la generalidad de los procesos de negocios. A partir del modelo de un proceso va a ser posible generar los componentes necesarios que permiten ejecutar la lógica del proceso modelado en diferentes plataformas de software destino. Como BPMN es un lenguaje con una sintaxis y semántica bien definida este artículo propone un DSL[4] gráfico para modelar los procesos con la notación seleccionada dentro de una herramienta que a su vez soportase la generación de código para producir los artefactos que permitan integrar el proceso de negocio en una aplicación huésped.

Esta solución computacional, a la que hemos denominado BPMN Studio, por sus características puede

considerarse una Fábrica de Software [5], ya que debe poder generar soluciones que puedan ser desplegadas sin requerir de la asistencia de un programador. Como no es posible contemplar todos los potenciales escenarios de ejecución, BPMN Studio debe ser extensible con la intensión de permitir a un equipo de desarrollo personalizar tanto su funcionamiento como la salida que genera para una determinada plataforma de software. Para ello la herramienta debe ofrecer facilidades para el desarrollo de extensiones que podrán ser incluidas sin necesidad de modificar directamente la propia herramienta.

1 Es un consorcio de once empresas estadounidenses fundado en 1989 que tiene como uno de sus principales objetivos

estandarizar la programación basada en modelos. Algunas de esas empresas son: Hewlett-Packard, IBM, Sun

Microsystems, Apple Computer, American Airlines y Data General. Uno de sus estándares más conocidos es UML. 2 Lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta

lógica de negocio añadida que ayuda a la programación en gran escala

2. Trabajos relacionados

Los BPMS son herramientas de software que tienen como objetivo modelar, transformar, ejecutar y gestionar procesos dentro del marco empresarial. Convertir un modelo expresado en una notación gráfica en un proceso ejecutable y supervisable requiere utilizar varias tecnologías. Es esencial una Herramienta de Transformación que permita transformar el modelo en una abstracción que pueda ser ejecutada en un Motor de Ejecución de Procesos que incorpore además el Análisis de Reglas de Negocio. Cuando estas tecnologías se proveen como un sistema integrado tenemos lo que se le llama BPMS. Estos BPMS se caracterizan por tener un ambiente de desarrollo cerrado, dirigidos a un escenario de ejecución específico. Ejemplos de BPMS de carácter comercial son Oracle SOA Suite [6], IBM BPM [7] y BizAgi BPM Suite [8], también los hay gratuitos y de código abierto como Intalio BPMN Community Edition [9], jBPM [10], Bonita Open Solution [11] y ProcessMaker [12], o incluso gratuitos pero con código cerrado como por ejemplo Activiti Modeler [13]. Ninguno de los antes mencionados se basa en la idea de usar un DSL para llevar a cabo la modelación de procesos de negocios y traducirlo luego a código ejecutable que permita su puesta en práctica e instanciación de los procesos, que es el enfoque que se propone en este trabajo.

Hay enfoques que se basan en la construcción de un DSL con el objetivo de modelar procesos de negocios, como es el caso de DSL4BPMN[14] que emplea elementos comunes de BPMN para la modelación e incluye una etapa de transformación que permite traducir el proceso modelado a notación BPMN en su estándar 2.0 pero se queda ahí, es decir no ofrece una solución para hacer ejecutable el modelo producido.

Otro enfoque como el expuesto en el artículo “A Methodology for Graphical Modeling of Business Rules”

[15] se basa en usar un DSL para la creación de reglas de negocios a través del uso de la notación BPMN. Luego estas reglas de negocios gráficas son modeladas con la intención de ser transformadas a reglas de Drools[16] (que es una de las plataformas para el manejo de reglas de negocios más usadas en la comunidad de Java) pero este enfoque no es extensible para adaptarlo a otro escenario destino.

3. Arquitectura de BPMN Studio

Una Fábrica de Software debe tener múltiples componentes que se encarguen de crear y ensamblar

un producto que va a actuar como solución a un determinado problema. Para lograr esta funcionalidad, el diseño de BPMN Studio fue separado en módulos agrupados en dependencia del rol del desarrollador que debería llevar a cabo su creación. El propósito de esta división en módulos es conseguir que BPMN Studio sea lo suficientemente extensible para permitir la personalización de su funcionamiento.

El dominio sobre el que se llevaría a cabo la arquitectura de las soluciones que produzca BPMN Studio son los procesos de negocios bajo la notación de BPMN 2.0. Para modelar procesos basados en esta notación este trabajo propone la creación de un DSL gráfico del que se pueda derivar un proceso de transformación que conduzca finalmente a la integración de los procesos de negocio para una plataforma de software concreta. La definición de este DSL constituirá en este caso la base de la Fábrica de Software que se pretende diseñar, porque con ello se controla el modelado del proceso de negocio y, a partir del modelo resultante, la generación del producto encargado de integrar este proceso de negocio en la solución final. ¿Por qué hablamos de una Fábrica de Software y no solamente de un DSL más? La distinción fundamental es la presencia de un Marco de Trabajo para la Extensibilidad que va a permitir personalizar el comportamiento de los elementos que conforman el DSL y poder adicionar y manejar múltiples generadores de código. Para lograr esto, el desarrollador del DSL debe definir diferentes tipos de abstracciones para representar las funcionalidades que pretenden ser extendidas, las cuales deben ser

implementadas fuera del contexto de desarrollo de la herramienta por los arquitectos de software que quieran adaptar la fábrica a necesidades específicas (Figura 1).

Figura 1: Diseño de BPMN Studio

Una de las limitaciones de usar un DSL es que con éste no se controla todo el flujo de desarrollo del proceso de negocio. Con el DSL se pueden cubrir dos etapas esenciales, que son el modelado y la generación de componentes, pero no se puede expresar cómo integrar el producto generado en el ambiente de ejecución concreto al que está orientado.

Figura 2: Etapas de desarrollo de una solución en BPMN Studio

La Figura 2 muestra las tres etapas que se encargan de crear y desplegar un proceso modelado. En la etapa 2 además de llevarse a cabo el proceso de transformación del modelo, debe preparar las condiciones para su integración. Para ello el DSL debe estar asociado a un Generador que convierta el proceso modelado gráficamente en una abstracción que pueda ser manejada y ejecutada en la plataforma de software a la que se dirige el producto. Este Generador debe ensamblar el producto generado de forma tal que se pueda instalar automáticamente en el ambiente de ejecución final. Por lo tanto, para realizar la 3ra etapa que se muestra en la figura, la aplicación cliente debe conocer el tipo producto que es generado por la fábrica con el propósito de llevar a cabo su integración.

4. DSL para la modelación de procesos de negocios

Para el diseño y desarrollo de un DSL es necesario cumplir principalmente con dos requisitos: conocer el dominio del problema del cual se busca dar solución y saber usar las herramientas de software que permitan especificar dicho dominio mediante el empleo de un lenguaje de meta modelación [17] que permita recoger la sintaxis abstracta, la sintaxis concreta y parte de la semántica del DSL.

La Sintaxis Abstracta del DSL define los conceptos y relaciones relevantes para el dominio de aplicación, pero no el modo en que se representan visualmente. Se le denomina entonces Sintaxis Concreta a una representación visual de la sintaxis abstracta. De esta forma es posible asociar una interfaz gráfica a los elementos del dominio que permita modelar visualmente los procesos de negocios.

Puesto BPMN es una notación compleja por el gran número de elementos que la componen y por todos los patrones de flujos de proceso que pueden formarse a partir de estos, crear un DSL basado en todos los elementos de BPMN puede resultar muy costoso de implementar y va más allá de los objetivos que se intentan demostrar. Por tal motivo, se decidió utilizar solamente un subconjunto de BPMN lo suficientemente expresivo como para poder modelar la generalidad de los procesos de negocios.

En la

Figura 3 se muestra un análisis estadístico que describe cuáles son elementos de BPMN que más se utilizan en el momento de especificar un proceso[18].

Figura 3: Estadísticas del número de elementos de BPMN utilizados como promedio en la modelación de procesos de negocios

A partir de análisis de los valores de esta gráfica se propone la elección de los siguientes elementos para definir el DSL:

Carriles (Lanes): Se utilizan para representar los individuos que intervienen en la ejecución del

flujo de un proceso. Más del 50% de los procesos utilizan menos de 5 Carriles, mientras que una

tercera parte tiene entre 5 y 10 Carriles.

Eventos (Events): Se utilizan para modelar la ocurrencia de un evento en particular. En BPMN hay

definido tres tipos de eventos: los Eventos de Inicio (que se utilizan para indicar el inicio del

proceso), los Eventos de Cierre (que definen el final del proceso, o de un subproceso) y los

Eventos Intermedios (que indican eventos que pueden ocurrir durante la ejecución de la proceso).

Más del 40% de los procesos tienen entre 5 y 10 eventos; de hecho, el 22% de los procesos pueden

llegar a tener entre 11 a 15 eventos.

Actividades (Activities): Se utilizan para especificar las acciones que deben llevarse a cabo

durante la ejecución del proceso. Dentro de esta categoría entran las Tareas (Tasks) y los

Subprocesos (Subprocesses). De la gráfica podemos deducir que más del 80% de los procesos

de negocios utilizan más de 11 tareas. Por otra parte, más del 80% de los procesos de negocios

tienen menos de 10 subprocesos.

Compuertas (Gateways): Se utilizan para definir varias rutas en el proceso. En BPMN existen

cinco tipos de compuertas pero las más utilizadas son: la Compuerta Exclusiva, Inclusiva y

Paralela. La Compuerta Exclusiva se utiliza cuando queremos definir caminos mutuamente

exclusivos, mientras que la Inclusiva permite que haya más de un posible camino por donde

pudiera irse la ejecución del flujo. La Compuerta paralela se utiliza cuando se requiere ejecutar en

paralelo más de un camino. Según la gráfica casi el 90% de los procesos de negocios tienen entre

5 y 15 compuertas definidas.

Artefactos (Artifacts): Se utilizan para mostrar información que ayuda al usuario a entender el

proceso, por lo que la semántica de ejecución de un proceso no está influenciada por ellos. En esta

categoría entran por ejemplo las Anotaciones de Texto, que son semejantes a los comentarios

en un lenguaje de programación tradicional. En general más del 75% de los procesos tienen menos

de 10 artefactos definidos.

El resto de los elementos como los Pisicinas (Pools), las Coreografias (Choreografies) y las Conversaciones (Conversations) recomendamos no incluirlos en la definición del DSL ya que son los menos usados al modelar procesos (más del 75% de los usuarios utiliza menos de 5 Pools mientras que el 85% de los usuarios no utilizan Coreografías ni diagramas de Conversación).

5. Marco de Trabajo para la Extensibilidad

Como Fábrica de Software BPMN Studio debe disponer de un marco de trabajo para la extensibilidad de forma de poder personalizar el comportamiento de los elementos que componen el DSL y poderle adicionar Generadores de Productos que se desarrollen externamente. Este Marco de Trabajo se basa en la aplicación del Patrón de Inversión del Control (IoC)[19].

Para poder aplicar este patrón en BPMN Studio es necesario implementar una biblioteca que incluya

todas los tipos interfaces que luego deberán implementarse por las dependencias que se deseen poder inyectar al invertir el control (Figura 4). De esta forma es posible desarrollar extensiones fuera del contexto del desarrollo de BPMN Studio, ampliando o adaptando sus funcionalidades sin necesidad de modificar el código de éste.

Figura 4: Funcionamiento del Marco de Trabajo para la Extensibilidad en BPMN Studio

Para usar las dependencias en BPMN Studio es necesario crear otra biblioteca en la que se defina el Contenedor de IoC, el cual debe contar con las funcionalidades de registrar y devolver las dependencias a partir de las Interfaces que estas implementan. De esta forma, un módulo de BPMN Studio podría solicitar al Contenedor todas las dependencias registradas para una determinada Interfaz.

6. Extensiones para modificar el modelo

La posibilidad de añadir nuevas extensiones en BPMN Studio tiene lugar en determinados elementos del DSL con la intención de personalizar la modelación del proceso de negocio y, permitir agregar además nuevos generadores a la herramienta. Para ello definimos en BPMN Studio tres tipos de extensiones: Acciones, Operandos y Generadores de Productos.

6.1 Acciones

El elemento Task es la unidad básica de un modelo de proceso basado en BPMN. Se utiliza cuando queremos representar de manera abstracta una operación que se desea realizar en un determinado paso del flujo (el ”Qué”). Para poder definir el “Como”, es necesario recoger información del modelador del proceso que permita especificar la lógica de negocio de la operación representada por la Tarea. Con este objetivo se definió un tipo de extensión de BPMN Studio llamado Acción. A cada Tarea va a ser necesario asignarle una Acción, la cual se va a definir como una propiedad del elemento Tarea. La información que se obtiene a través de las Acciones va a ser utilizada por un Generador con la intensión de ayudar a crear el producto que finalmente se integraría a una plataforma de software concreta.

Las Acciones van a ser agregadas mediante el Motor de Extensibilidad de BPMN Studio y se desarrollan

de forma independiente a la herramienta (Figura 5). Cuando se selecciona una Tarea durante la modelación de un proceso se va dar la posibilidad de elegir entre todas las Acciones definidas. Cada acción debe tener definida una Interfaz Gráfica y un API para la Serialización (Error! Reference source not found.). La primera sería utilizada para interactuar y recoger información del usuario del DSL. El API de Serialización sería el encargado de salvar esa información como parte del modelo del proceso.

Figura 5: Uso de una Acción en BPMN Studio

6.2 Reglas de Negocio

Generalmente los procesos de negocio no tienen un comportamiento puramente secuencial. Muchas veces es necesario dividir un flujo en más de un camino en dependencia del cumplimiento de una o varias condiciones. Con este propósito es que en BPMN Studio se usan las Reglas de Negocios, que no son más que reglas lógicas empleadas en la toma de decisiones.

En BPMN Studio, los elementos de BPMN que son usados para separar un flujo en varios caminos son

la Compuerta Exclusiva e Inclusiva. Para cada camino por los que se separe el flujo (usando uno de estos dos elementos) se va a definir una Regla de Negocio.

Las reglas de negocio modeladas juegan un rol fundamental en este paso, ya que son usadas para la

creación de condiciones que separen realmente el flujo del proceso una vez que la representación de este sea ejecutada.

Una regla de negocio en BPMN Studio está compuesta por dos Operandos y un Operador. Las

operaciones permitidas son: estrictamente menor (<), estrictamente mayor (>), menor o igual (<=), mayor o igual (>=), igual (=) y desigual (<>).

Figura 6: Ejemplo de Reglas definidas para una Compuerta Exclusiva

6.3 Operandos

Los Operandos, al igual que las Acciones, se definen como un tipo de abstracción propia de BPMN Studio. Al igual que las acciones esto permite que la implementación de Operandos se pueda hacer externamente para luego ser añadida como extensión posibilitando personalizar la modelación de las Reglas de Negocios. Tener solo un conjunto estático de Operandos dificulta modelar todas las posibles condiciones que pudieran llevar a la separación de un flujo. Haciendo extensible este punto, se pueden crear en demanda nuevos Operandos, lo que permitiría modelar nuevas condiciones.

El objetivo del Operando es representar un valor con el cual se pueda comparar. En BPMN Studio se

incluyen dos tipos de Operandos: los que dependen a su vez de alguna abstracción ya definida en BPMN Studio como alguna Acción (por ejemplo un Operando basado en una Acción para el modelado de la llamada a un servicio web) y los que son implementados independiente de otras componentes del modelo (por ejemplo un Operando que permita consultar el campo en una tabla de una Base de Datos).

Al igual que las Acciones, los Operandos deben definir una interfaz gráfica que permita especificarlos

durante el modelado y un API para la Serialización. Luego que el Motor de Extensibilidad provea al Modelador de Reglas de Negocios todos los Operandos implementados, el modelador podrá elegir los Operandos a utilizar en una regla. En dependencia de esa elección, debe ser cargada la visualización del Operando.

7. Definición del tipo de flujo de trabajo Process

Los flujos de trabajo son una forma natural de expresar la coordinación de tareas asincrónicas, especialmente cuando el proceso de negocio hace llamadas a servicios externos. Son realmente útiles cuando el proceso de negocio es de larga duración (como puede ser por ejemplo un trámite que involucre varias aprobaciones de humanos).

De la notación de un proceso en BPMN se pueden inferir varios patrones de flujos trabajo [20]. De modo que es posible definir un tipo de flujo de trabajo que podría utilizarse para expresar la transformación del modelo obtenido con el DSL en un producto ejecutable. Para facilitar esta tarea, se propone la creación de un tipo de flujo de trabajo, que denominamos Process, basado en el subconjunto de elementos de BPMN que se presentaron en la sección 4. A partir de los mismos, es posible formar patrones de flujos de trabajos tales como Sequence, Parallel Split, Synchronization, Exclusive Choice, Arbitrary Cycle, Implicit Termination, Multiple Instances.

Un Process se conformar primero con elementos Lanes que identifican los individuos que intervienen

en la ejecución del flujo de un proceso. En cada Lane se utilizan los elementos Eventos, Actividades y Compuertas que serán los encargados de ejecutar la lógica modelada en el proceso.

8. Creación y Manipulación de Generadores de Productos

Una Fábrica de Software normalmente da como salida un producto que es una solución en un determinado dominio del negocio o problema al que está dirigido. Para el caso de BPMN Studio es posible establecer diferentes generadores encargados cada uno de realizar la transformación de la información recogida en el modelo de un proceso hacia un producto que pueda ser desplegado en un sistema de software concreto. De esta manera un mismo proceso de negocio podría ejecutarse en múltiples plataformas o un modelador escoger en qué plataforma quiere ejecutar el resultado de su modelado.

Los generadores de BPMN Studio se desarrollan externamente y se agregan mediante el Motor de

Extensibilidad. El DSL utiliza dicho motor para cargar los generadores disponibles y le da la opción al modelador de elegir cual utilizar luego de modelado el proceso. Una vez elegido, el DSL le solicita al Motor de Extensibilidad el generador seleccionado y da la orden de generar el producto (Figura 7).

Figura 7: Generación e integración de un producto en BPMN Studio

En la creación de un generador hay que tener en consideración varios aspectos. Obviamente primero hay hay que identificar hacia cuál plataforma de software se va a generar. Esta plataforma debe incluir el manejo

manejo de flujos de trabajo para que el generador solo tenga que transformar el modelo del proceso a un tipo de flujo con las características descritas en la sección anterior. Esto posibilitaría llevar a cabo una

transformación más directa de los elementos del modelo a los elementos del flujo. Esa transformación debe encargarse además de definir en cada elemento del flujo la operación a realizar a partir de la interpretación de la lógica de negocio que haya sido a su vez añadida haciendo uso de las Acciones y Reglas de Negocios

definidas en el modelo. Para eso por supuesto el generador debe poder entenderse con las extensiones que que fueron utilizadas para poder llegar a procesarlas. Puede incluso ser necesario generar contenidos que apoyen a la realización de una determinada operación, como por ejemplo, la creación de un formulario web

que se utilice para recoger información en un determinado paso del flujo. Estos contenidos tendrán que quedar instalados en la aplicación cliente3 y van a formar parte del producto final que genera la fábrica (

Figura 8).

Figura 8: Etapas por las que pasa un generador de BPMN Studio

9. Integración de los procesos generados

Por último pero no menos importante sería definir la forma en que se instalaría y consumiría el producto generado. La decisión de cómo se debería realizar este proceso depende del desarrollador del generador de código y de la tecnología utilizada para desarrollar la aplicación donde se hospedarían y/o consumirían los flujos4. Con el hecho de facilitar esta tarea, presentamos a continuación dos enfoques referentes a la arquitectura que deben seguir las aplicaciones involucradas en este proceso de integración.

9.1 Integración básica

El primer enfoque propone que la aplicación donde se instale el producto debe estar preparada para integrar, manejar y poner a disposición del usuario el flujo de trabajo generado (Figura 9). Para lograr todas estas funcionalidades la aplicación debe contar con un Motor de Ejecución de Flujos de Trabajo y una Base de Datos donde se pueda persistir la información de cada proceso. Para que el usuario pueda consumir un flujo de trabajo es necesario que la interfaz gráfica de la aplicación esté preparada para mostrar los procesos de negocios registrados. De esta forma se completaría el despliegue automático del producto generado por la fábrica. Este enfoque es el más sencillo y facilita mucho el proceso de integración, dado que los flujos generados son manejados y consumidos por una misma aplicación. Su aspecto negativo radica en que pudiera afectar el rendimiento de la aplicación si se manejan un número significativo de instancias de flujos.

4 Puede que la aplicación donde se hospeden los flujos de trabajo no sea la misma donde posteriormente se consuman.

Figura 9: Generación e integración de los flujos de trabajo en una misma aplicación

9.2 Integración usando un Servidor de Flujos

El segundo enfoque es más complejo que el anterior debido a que involucra dos aplicaciones, una que actuaría como servidor y que sería la encargada de hospedar los flujos de trabajos generados por la fábrica, y otra que actuaría como cliente con el propósito de dar acceso a los usuarios de consumir los flujos hospedados (Figura 10). De esta manera se liberaría a la aplicación cliente de tener que manejar directamente la ejecución de los flujos de trabajo. Pero, este enfoque hace que inmediatamente nos hagamos dos interrogantes: ¿cómo en un mismo proceso de instalación se puede modificar dos aplicaciones? y ¿cómo se establecería la comunicación entre ambas aplicaciones para llegar a consumir los flujos desde la aplicación cliente?

Lo primero que es necesario identificar es el punto de partida donde se llevaría a cabo este proceso de

integración. El generador basado en este enfoque va a tener que incluir dos procesos de instalación en el producto que genera, uno para hospedar el flujo en el servidor y otro para registrarlo en la aplicación cliente, lo que puede conllevar además a la instalación de otros componentes que permitan el consumo y ejecución del flujo por el usuario final. Dada la mayor complejidad de este último, se propone iniciar ambos procesos de instalación desde la aplicación cliente. Pero, ¿cómo se puede mandar a hospedar un flujo en el servidor desde la aplicación cliente? Para eso, el servidor debe poner a disposición de la aplicación cliente un servicio web que permita llevar de manera remota tanto despliegue de los flujos como el consumo de sus instancias. Esta idea está basada en el Manejador de Flujos de SharePoint[21].

Figura 10: Generación, integración y consumo de flujos de trabajo a través de un servidor externo

10. Conclusiones

El diseño computacional de esta herramienta demuestra que es posible hacer uso de un DSL con el objetivo de modelar procesos de negocios basados en BPMN. Mediante el proceso de generación del DSL, los procesos modelados pueden ser integrados en diferentes tipos de aplicaciones en dependencia de la tecnología o plataforma que fue utilizada para su desarrollo. La capacidad de extensibilidad debe ser una característica fundamental de una tal herramienta de modo de poder añadir nuevos componentes a los elementos del dominio que conforman el lenguaje y agregar nuevos generadores de productos.

El uso de una herramienta como BPMN Studio debe constituir un ahorro considerable de tiempo y

recursos una vez creada la infraestructura en la aplicación cliente donde se desea hospedar y ejecutar los procesos. Está concebida para ser usada por modeladores, evaluadores, administradores de proyectos y analistas de negocio. La integración de los procesos se debe realizar de forma automática y sin requerir de la asistencia de un programador mediante la adaptación, montaje y configuración de componentes como flujos de trabajo, páginas, formularios, entre otros.

Se ha desarrollado una implementación de BPMN Studio sobre Visual Studio .NET que aprovecha a su

vez el marco de trabajo para la extensibilidad y las capacidades para crear DSLs gráficos que el propio Visual Studio .NET ofrece. También se ha desarrollado un caso particular de extensión orientado a escenarios de ejecución del producto final en una plataforma basada en Sitefinity (CMS basado en ASP .NET que incluye ….) y que actualmente se está comenzando a aplicar en un proceso de negocio para la tramitación de gestiones legales de la ciudadanía de una localidad.

La extensión con otros generadores de producto puede ser objeto de futuras implementaciones.

11. Referencias

1. Wil M. P. van der Aalst, A.H.M.t.H., Mathias Weske, Business Process Management: A Survey. Lecture Notes in Computer Science, 2003.

2. Group, O.M. Documents Associated with Business Process Model and Notation (BPMN) Version 2.0. January 2011; Available from: http://www.omg.org/spec/BPMN/2.0.

3. Sinur, J., Hill, J., Magic Quadrant for Business Process Management Suites. Gartner, 2010. 4. Fowler, M., Domain Specific Languages. 2010: Addison-Wesley Professional. 5. Jack Greenfield , K.S., Steve Cook, Stuart Kent, John Crupi, Software Factories: Assembling

Applications with Patterns, Models, Frameworks, and Tools. 2004: John Wiley & Sons. 6. Oracle, Oracle Business Process Management Suite 11g. 7. IBM, IBM Business Process Manager, v 8.5. 8. BizAgi, Bizagi BPM suite 10.1. 9. Intalio, Intalio BPMN Community Edition. 10. Hat, R. Pagina oficial jBPM. Available from: http://www.jboss.org/jbpm/. 11. BonitaSoft, Bonita Open Solution, Open Source BPM. 12. Maker, P., ProcessMaker Workflow management and BPM. 13. Activiti, Activiti BPM Platform. 14. Heitkotter, H., A Framework for Creating Domain-specific Process Modeling Languages. 15. Daniele Di Bona, G.L.R., Giovanni Aiello, Adriano Tamburo, Marco Alessi, A Methodology for

Graphical Modeling of Business Rules. European Symposium on Computer Modeling and Simulation, 2011.

16. JBoss. Pagina Oficial de Drools. Available from: http://www.jboss.org/drools/. 17. Sztipanovits, M.E.a.S.N.a.J., Metamodeling Languages and Metaprogrammable Tools. Institute for

Software Integrated Systems, Vanderbilt University. 18. Michele Chinosi, A.T., BPMN: An introduction to the standard. Computer Standards & Interfaces,

2012. 19. Fowler, M. Inversion of Control Containers and the Dependency Injection pattern. 2004; Available

from: http://www.martinfowler.com/articles/injection.html. 20. White, S., Process Modeling Notations and Workflow Patterns. IBM Corp. 21. Pialorsi, P., Microsoft SharePoint 2013: Developer Reference. O'Really.

View publication statsView publication stats