Informe 2006 Formalización de modelo de recursos

De MorfeoWiki

Grupo de trabajo SmartFlow, Universidad de León

• Adolfo Rodríguez de Soto
• Eva Cuervo Fernández
• Conrado Andréu Capdevila

---

Tabla de contenidos 1 Un motor de workflow con gestión de recursos 2 Introducción 3 Terminología 4 La componente SmartFlow-Engine 5 Componentes de gestión de recursos 6 Ampliación del lenguaje de definición de procesos 6.1 Codificación de la definición de una tarea. 7 Patrones de recursos 7.1 Tabla de patrones 8 Conclusiones 9 Referencias

Un motor de workflow con gestión de recursos

En este trabajo se presentará el diseño de varias componentes software que permitirán la creación y gestión de procesos de negocio que requieren de recursos humanos para su realización. La solución propuesta será una ampliación de la componente de Workflow, construida alrededor del motor SmartFlow-Engine, incluida en el proyecto Morfeo. Los requerimientos de la solución se han obtenido a partir de un conjunto de patrones de recursos, lo que ha permitido determinar un diseño genérico y flexible. El objetivo final es conseguir una gestión de procesos que permita asignar los recursos requeridos para llevar a cabo esos procesos así como analizar el uso de recursos humanos dentro de una organización.

Introducción

Los sistemas de información orientados a la gestión de procesos de negocio [2] se están convirtiendo rápidamente en una herramienta fundamental tanto para las empresas, en su objetivo de lograr una mayor competitividad y eficiencia, como para las administraciones públicas, en su afán de conseguir una mejor relación con el ciudadano. La representación explícita de los procesos de una organización en sus sistemas de información debe favorecer su control y análisis así como la definición de nuevos procesos o la modificación de los existentes. La situación actual del mercado de este tipo de aplicaciones software es muy dispersa, cada desarrollador ofrece su solución propietaria y no existe ningún tipo de estándar consolidado que facilite la definición de procesos a pesar de la aparición de lenguajes como XPDL [11] o BPEL [1]. Como se indica en [12], se requiere de una mayor fundamentación teórica para conseguir un estándar común en la definición de procesos de negocio.

Y es que los procesos de negocio presentan diversos y complejos aspectos que no son cubiertos completamente por ninguna de las herramientas conocidas, tanto comerciales como de código abierto. En concreto tres son las perspectivas importantes cuando se habla de gestión de procesos: flujo de control, gestión de datos y gestión de recursos. Y aunque hay discrepancias respecto al modelo teórico adecuado para fundamentar el flujo de control de procesos, especialmente entre el uso de álgebras de procesos tipo pi-calculus [7] o las redes de petri extendidas [5], ver por ejemplo [13], las herramientas de gestión de procesos basadas en motores de workflow habitualmente representan de forma adecuada, desde luego unas mejor que otras, el flujo de control de los procesos. La responsabilidad de la gestión de datos se deja normalmente en manos de gestores de bases de datos. En cambio se ha puesto mucha menos atención a la gestión de recursos, y sin embargo éste es un aspecto crucial para construir sistemas de gestión de procesos realmente interesantes para las organizaciones. La posibilidad de que el sistema facilite la asignación de recursos a tareas, registre los sucesos en torno a su resolución por los recursos o las incidencias que alrededor de la gestión de recursos pueden surgir en la realización de los procesos, constituye una fuente de información muy importante a la hora de realizar un análisis de procesos que permita su mejora. No es suficiente con la visión de control o de datos, son las personas las que al final realizan una gran parte del trabajo de los procesos en las organizaciones y éstas tienen la necesidad de realizar un análisis de la eficiencia de sus procesos, del impacto de la introducción de un nuevo proceso, del uso de los recursos, de la eliminación temporal o permanente de recursos, etc.

Los motores de workflow pueden constituirse como núcleo de los sistemas de gestión de procesos si se orientan hacia una visión más general de los procesos de las organizaciones y evitan centrarse únicamente en su funcionalidad habitual de control de procesos totalmente automatizados. A los motores de workflow habrá que añadirles control de procesos que involucran trabajos manuales, mecanismos para la integración y coordinación de servicios y aplicaciones, mecanismos de transacciones, gestión de excepciones, herramientas de monitorización de procesos, herramientas de análisis y simulación, etc.

En este trabajo se ha abordado la posibilidad de implantar un sistema de gestión de recursos en la componente de workflow del proyecto Morfeo [9] como un paso requerido para convertir el motor de workflow en una herramienta de gestión de procesos. Morfeo es una comunidad de Software Libre constituida por un consorcio de empresas, universidades y organismos de investigación que tiene como objetivos, entre otros, acelerar el desarrollo de estándares software relacionados con arquitecturas orientadas a servicios. Una de las componentes CORBA que en la actualidad contiene el repositorio de Morfeo es el motor de workflow SmartFlow-Engine liberado por Telefónica I+D y componente principal del subproyecto SmartFlow que se desarrolla en el marco del proyecto Morfeo.

Terminología

En el mundo de la gestión de procesos y de workflow la terminología está muy de lejos de estar unificada. Un ejemplo de ello es precisamente la componente SmartFlow-Engine en la que la terminología actual queda bastante limitada cuando se introducen nuevos requisitos para su ampliación. En este trabajo se ha preferido utilizar la terminología de workflow tal como se utiliza en [12] a pesar de entrar en conflicto con la terminología actual de la SmartFlow-Engine.

Se considerará que un modelo de workflow es la descripción no ambigua de un proceso de negocio. Una tarea es cada uno de los pasos, o unidades de trabajo, que eventualmente hay que realizar para completar un modelo de workflow. Un caso es una instancia de un modelo de workflow o una instancia de proceso de negocio. Se supone que los casos son independientes entre sí y no tienen referencia entre ellos. Un item de trabajo es la ejecución de una tarea para un caso, es decir la instanciación de una tarea. Por último una actividad es la realización de un item de trabajo.

En la componente SmartFlow-Engine se denomina red a un modelo de proceso y el témino de tarea representa un caso. Éste último conflicto de terminología es especialmente desafortunado puesto que al hablar de gestión de recursos se requiere distinguir entre tareas con recursos y tareas sin recursos, algo que no tiene sentido si se considera una tarea como un caso, puesto que se supone que, eventualmente, todos los casos de un proceso requerirán el mismo tipo de recursos. En las tareas que no requieren recursos se incluyen también aquellas que se pueden realizar automáticamente, porque, aun necesitando recursos, éstos son automáticos y no tienen una limitación de tiempo, de asignación o de carga de trabajo. Las tareas que requieren recursos están limitadas en algún sentido, por número, por tiempo, por carga de trabajo, etc.

A continuación se describen las principales características del motor de workflow SmartFlow-Engine.

La componente SmartFlow-Engine

SmartFlow-Engine (en su versión 1.2.0) se presenta como un servicio CORBA para la gestión de procesos modelados mediante el formalismo de las redes de Petri binarias, es decir 1-acotadas o seguras. La componente está diseñada con el objetivo de ofrecer una solución general que pueda aplicarse en ámbitos diversos, lo que en parte determina que el desarrollador deba trabajar a un nivel de abstracción bastante bajo. Tanto los datos propios de la gestión de procesos registrados en el sistema, como los datos operativos e históricos de los casos se mantienen en una base de datos.

El punto de entrada a la componente es una interfaz IDL para un servicio de gestión de definiciones de procesos. A la hora de desplegar una nueva definición se deben proporcionar varios elementos:

• Un archivo XML con la definición de la estructura de la red de Petri asociada, los eventos que hacen cambiar el estado de la red y las acciones asociadas a transiciones y lugares de la red. El lenguaje que debe utilizarse se denomina PNML [3], aunque es diferente al PNML definido en [10].
• Varias clases Java que implementan parte de ese comportamiento, como las acciones y transformaciones de eventos, y clases Java para la persistencia de datos.

El desarrollo de un modelo de proceso comienza con la redacción de un documento PNML que incluye la definición de la red de Petri asociada. En esta red se pueden etiquetar tanto los lugares como las transiciones con acciones a realizar en ejecución, que deberán ser proporcionadas por el desarrollador en forma de código Java.

Por otra parte, se definen también eventos externos que harán evolucionar el estado de la red. Los eventos externos se procesan para habilitar algunas transiciones de la red de Petri. Si estas transiciones habilitadas tienen además todos sus lugares de entrada marcados, la máquina de estados las disparará y ejecutará las acciones asociadas a los lugares y transiciones involucrados.

El documento PNML se compila para generar los esqueletos de clases Java para las acciones y transformaciones de la red. El desarrollador debe ahora completar estas clases y registrar la red en la máquina de estados. Una vez registrada la red, se puede solicitar la creación de casos del proceso. Comienza entonces el ciclo de vida del caso que se resume en el procesamiento de eventos y en la consecuente evolución de su estado a través de la red asociada.

Componentes de gestión de recursos

En la figura se muestra la red de Petri que modela el ciclo de vida de una tarea que requiere recursos. Cuando se define un proceso que incluye tareas que requieren recursos, se creará un nuevo caso de esta red para cada una de esas tareas. Como se verá posteriormente, al definir una tarea con recursos el sistema incorpora a la red de Petri original, que denominaremos red padre, todo lo necesario para crear un caso de red de recursos y modelar así el estado de la tarea en lo que a recursos se refiere.

La red de gestión de recursos está basada en [8] y ha sido ampliada para incluir la asignación temprana de tareas. En la parte izquierda se modela la asignación de un recurso al item de trabajo. El sistema de gestión de items de trabajo puede realizar una asignación directa u ofrecer la tarea a uno o a varios recursos. A su vez los recursos pueden delegar la asignación de un item de trabajo. En la parte derecha se refleja la ejecución del item de trabajo, que puede ser suspendida, finalizada con éxito o fallida. Cuando un item de trabajo que ha requerido un recurso finaliza la red de recursos emitirá un evento a la red padre indicando su finalización.

La red de gestión de recursos puede recibir eventos tanto de los propios recursos, a través de la aplicación worklist o bandeja, como del gestor de items de trabajo. En el primer caso se etiquetan las transiciones como "r" y en el segundo como "s".

La solución propuesta para la gestión de recursos aparece en la siguiente figura.

Además del motor de workflow, la componente SmartFlow-Engine, se definen tres componentes que pasamos a describir:

• ResourcesManager — Es la componente encargada de gestionar los recursos de la organización. En [8] se da un diagrama de rol de objetos (Object Role Diagram [6]) con un modelo de recursos que incluye tanto características de recursos humanos como no humanos, clasificados por roles, grupos o posiciones. Este trabajo se centra únicamente en la gestión de recursos humanos. Esas características se requieren en alguno de los patrones de recursos estudiados. Esta componente la consideramos fuera de los límites del sistema a construir. Básicamente las exigencias que se le imponen es poder resolver peticiones de recursos según alguno de los criterios del modelo de recursos organizacionales propuesto, devolviendo una lista de los recursos que cumplen las condiciones dadas, labor que se realiza a través de la interfaz ResourceManager. Además debe avisar a la componente WorkItemsManager cuando algún recurso deja de estar disponible para que ésta reasigne los workitems asignados a ese recurso, labor que se realiza siguiendo el patrón Observador [4], siendo el sujeto la componente ResourcesManager y declarando la interfaz ResourceEventListener para el observador.
• WorkItemsManager — Esta componente es la responsable de gestionar las asignaciones de recursos a los workitems. Los recursos son solicitados a la componente ResourcesManager, pero es esta componente la encargada de decidir la política de asignaciones a recursos. En ella se implementarán las reglas de negocio que determinen esta política de asignaciones. Además mantendrá un histórico de las operaciones realizadas de cambio en el estado de asignación de recursos a los workitems en la tabla HumanResourcesAllocationHistory y las asignaciones propuestas sobre las que no se ha realizado aún una acción en la tabla ResourceAllocationAppoinment. La componente SmartFlow-Engine llamará a operaciones de la componente WorkItemsManager a través de la interfaz del mismo nombre. Las llamadas estarán provocadas por las acciones incluidas en la red de gestión de recursos.
• WorklistApplication — Una de las componentes más importantes en los sistemas de workflow, o de la gestión de procesos, es la encargada de mostrar los items de trabajo asignados u ofrecidos a un recurso humano. Esta componente, denominada también bandeja, permitirá al usuario registrarse para descargar todas las actividades que debe realizar. La componente WorklistApplication es la encargada de realizar estas tareas en nuestro sistema. Cuando un usuario se registre, la aplicación consultará a la componente WorkItemsManager cuáles son sus items de trabajo y sobre ellos podrá actuar, por ejemplo completándolos o delegándolos, entre otras acciones. Esas acciones provocarán eventos sobre la red de recursos que podrán cambiar el estado de asignación de un workitem o cambiar el estado de realización del mismo; la red comunicará entonces a la componente WorkItemsManager este cambio. La componente WorklistApplication solicitará al proceso padre que ha requerido una tarea con recursos los datos del caso necesarios para poder realizar el item de trabajo.

Ampliación del lenguaje de definición de procesos

En este trabajo se plantea la extensión del modelo de proceso que proporciona la máquina de estados SmartFlow-Engine. El objetivo es incluir la gestión de tareas con recursos, con los patrones propuestos en [8] como guía.

En primer lugar es necesario aumentar la capacidad del lenguaje PNML. Se ha definido un nuevo lenguaje (WDL) que incluye el modelo de proceso que se propone en el original y que además añade la posibilidad de definir tareas con recursos. Éstas contienen toda la información necesaria para la ejecución de la tarea, como expresiones para la asignación de recursos. Al compilar el documento de definición se añaden a la red de Petri original los lugares y transiciones necesarios para incorporar la gestión de recursos.

En la siguiente figura se representa la modificación de la red de Petri original para incorporar una tarea Tj con recursos. En la red final se añaden las operaciones necesarias para crear un nuevo caso de la red de gestión de recursos en Ta. La red principal queda entonces a la espera de la ejecución de la tarea, en el lugar Pa. La sub-red modela el estado de la tarea en relación con los recursos que necesita. Cuando alcanza su estado final, que indica que la tarea se ha realizado, envía un evento a la red principal. Éste provoca el paso al estado Pb en el que se espera entonces un posible evento del usuario sobre la transición Tj que en la red original indicaba la finalización de la tarea.

La definición del proceso se realiza según las reglas especificadas en la definición del lenguaje WDL, para generar un documento XML que incluye la red de Petri original y la definición de tareas con recursos. Este documento deberá ser compilado para que se realice el proceso de incorporación que se ha visto anteriormente y se generen así las clases Java y el documento de definición de la nueva red de Petri que deberán registrarse en la máquina de estados.

La definición de una tarea contiene expresiones de asignación de recursos, que han sido diseñadas con los patrones de recursos como guía. Se distinguen dos tipos de expresiones: Selección y Ordenación. En la evaluación de expresiones del primer tipo el resultado va a ser un conjunto de recursos que cumplen cierto criterio, como por ejemplo que tienen un role dado. Las expresiones de selección se pueden combinar mediante operadores básicos de conjunción, disyunción y negación, que se implementan respectivamente como intersección, unión y complemento de conjuntos de recursos. En el caso de las expresiones de ordenación, su papel es modificar un conjunto de recursos de entrada para establecer en él un orden según un criterio.

El diseñador del proceso debe indicar en cada tarea que necesite recursos las expresiones para que el gestor de items de trabajo evalúe la asignación y decida a qué recurso se asigna la tarea. Se supone que la organización tiene los recursos necesarios para la ejecución del proceso, por lo que si en un momento dado la evaluación ofrece un conjunto vacío como resultado, se considerará una anomalía y se señalará un estado de excepción.

Codificación de la definición de una tarea.

A continuación se incluye un fragmento de la definición de una tarea, en la que el diseñador solicita la asignación a un recurso que posea dos roles, developer y administrator. La tarea se asocia a la transición Tj de la red de Petri que aparece modelada en el mismo documento. Además se indica que el proceso tiene manejador del caso, lo que quiere decir, que el recurso que ejecute la primera asignación debería ejecutar el resto. Así mismo se puede especificar en la definición del proceso la lista de tareas incompatibles en cuanto a recursos, que en este ejemplo serían "fix bug" y "review fix", que deberían ser realizados por diferentes recursos.

…
      </wdl:JavaTransformation>
   </wdl:Transformation>
</wdl:ExtEvents>
<wdl:ResourceManagement>
   <wdl:Features>
      <wdl:feature xsi:type="wdl:caseHandling"/>
      <!-- other features: wdl:chainedExecution -->
   </wdl:Features>
   <wdl:Incompatibilities>
      <wdl:Incompatibility>
         <wdl:Assignment name="fix bug"/>
         <wdl:Assignment name="review fix"/>
      </wdl:Incompatibility>
   </wdl:Incompatibilities>
</wdl:ResourceManagement>
<wdl:Assignments>
   <wdl:Assignment name="fix bug" transition="Tj">
      <wdl:Features>
         <wdl:feature xsi:type="wdl:earlyDistribution"/>
         <wdl:feature xsi:type="wdl:canSkip"/>
         <wdl:feature xsi:type="wdl:piledExecution">
            <ae:selection xsi:type="ae:and">
               <ae:selection xsi:type="ae:directAllocation" resource="RA00012"/>
               <ae:selection xsi:type="ae:directAllocation" resource="RA00013"/>
            </ae:selection>
         </wdl:feature>
         <!-- other features: wdl:canPreDo, wdl:commenceOnAllocation
            wdl:commenceOnCreation, wdl:chainedExecution
         -->
      </wdl:Features>
      <wdl:Requirements>
         <ae:selection xsi:type="ae:and">
            <ae:selection xsi:type="ae:roleBased" role="developer"/>
            <ae:selection xsi:type="ae:roleBased" role="administrator"/>
         </ae:selection>
      </wdl:Requirements>
   </wdl:Assignment>
   …
</wdl:Assignments>
…

Patrones de recursos

Para fijar los requisitos de las componentes de gestión de recursos se ha utilizado principalmente el conjunto de patrones de recursos definido en [8]. A continuación se indica cómo se resuelven dichos patrones en la solución aquí presentada.

1. R-DA asignación directa (Direct Allocation): En la definición del proceso se puede especificar mediante una expresión que una tarea concreta se asigne siempre, en el momento que se cree, a un determinado recurso. En ejecución, el gestor de items de trabajo accede a esa definición y evalúa la expresión para localizar el recurso y asignarlo a la tarea. En este caso la evaluación se traduce a una consulta en la componente gestora de recursos para buscar un recurso a partir de su identificador.
2. R-RBA asignación basada en role (Role Based Allocation): Se especifica en diseño que una tarea solo puede ser ejecutada por recursos que tengan un determinado role. Se incluirá en la definición de la tarea mediante una expresión. Se pueden considerar los roles como un mecanismo de agrupamiento de recursos. Como subtipo de este patrón se podría considerar la asignación basada en grupos: se especifica en diseño que una tarea debe ser ejecutada por un recurso que sea miembro de un grupo. En tiempo de ejecución un workitem de dicha tarea se ofrece/asigna al grupo, y por tanto será visible en la bandeja/aplicación worklist de todos los miembros del grupo. En el momento en que un recurso indique que comienza a ejecutar el workitem, dejará de estar activo en las bandejas del resto del grupo, desapareciendo de las mismas cuando dicho workitem se complete. Otro aspecto a considerar en el futuro, sería especificar que una tarea deben llevarla a cabo X recursos pertenecientes a un grupo o que cumplan un determinado role. El gestor de workitems tendría que encargarse de dicha comprobación.
3. R-FBA asignación diferida (deFerred Allocation): Se especificará en diseño el nombre de la expresión que contendrá en ejecución las condiciones que debe cumplir el recurso/s a los que se ofrezca/asigne o ejecute la tarea. El gestor de items de trabajo incluye operaciones para registrar y consultar expresiones de asignación en ejecución.
4. R-RA Autorización ( authorization ): En la expresión donde se seleccionan los recursos se pueden establecer condiciones sobre privilegios o posiciones organizativas que estos tienen que tener dentro de la organización. Esta información la proporcionará el gestor de recursos consultando los datos del modelo organizacional.
5. R-SOD separación de tareas (Separation Of Duties): Se puede establecer en la definición del modelo de proceso el hecho de que para ciertas tareas de un caso, el recurso asignado sea diferente. Se implementa mediante la especificación en diseño de listas de tareas incompatibles en términos de recursos. El gestor de ítems de trabajo comprobará si la tarea actual pertenece a alguna de estas listas y en caso afirmativo consulta una tabla HumanResourcesExecutionHistory, para comprobar si para ese caso se ha ejecutado alguna de las tareas incompatibles. Si es así eliminará del conjunto de recursos candidatos aquellos que hayan realizado alguna tarea incompatible.
6. R-CH manejador de caso (case handling): Se puede indicar en la definición del proceso si todas las tareas de un caso se deben asignar al mismo recurso, mediante la característica “caseHandling”. El gestor de items de trabajo deberá distinguir si se trata de la primera tarea o no, consultando sus tablas de historial.
7. R-RF retener familiar (Retain Family): Una vez que se ha calculado el conjunto de recursos candidatos, se puede ordenar dicho conjunto eligiendo el recurso que haya ejecutado el workitem anterior del caso. Se establecerá en la expresión de ordenación de la definición de la tarea,.
8. R-CBA asignación basada en capacidades (Capability Based Allocation): En la expresión que define la tarea se pueden incluir requisitos referidos a capacidades que deben cumplir los recursos que la ejecuten. Esta información se obtendrá consultando al gestor de recursos.
9. R-HBA asignación basada en historial (History Based Allocation): Se trata de una forma de ordenación de los recursos candidatos obtenidos al aplicarle una selección. Se ordenarán en función de determinados datos almacenados sobre ejecuciones anteriores en una tabla “HumanResourceExecutionHistory”.
10. R-OA asignación organizacional (Organizational Allocation): En la expresión de selección de candidatos se establecerán condiciones a consultar al gestor de recursos puesto que esta información se halla en el modelo organizacional. Se podrá evaluar una expresión sobre el resultado de otra expresión estableciendo niveles de expresiones, para por ejemplo, encontrar el jefe del recurso que ejecutó un determinado workitem.
11. R-AE ejecución automática (Automatic Execution): Sería una tarea que no requiere recursos para su ejecución. No requiere implementación alguna. No se modificaría la red original para esta tarea, es decir, no se creará la subred de gestión de recursos.
12. R-DBOS distribución ofreciendo a un único recurso (Distribution By Offer Single resource): Se configura en el Workitems Manager para indicar si el workitem se ofrece a un único recurso o a todos los candidatos resultado de la expresión evaluada. En caso de ofrecerlo a un único recurso. Se genera el evento que dispara la transición “s_offer_s” en la red de recursos, se actualiza una tabla de workitems ofrecidos (“HumanResourceOfferHistory”) y se actualiza la bandeja del recurso correspondiente.
13. R-DBOM oferta a múltiples recursos (distribution by offer - multiple resources): Al seleccionar varios recursos para un item de trabajo, la oferta se notifica a todos ellos y cuando uno se ofrezca voluntario, se retira la oferta a los demás. Esta comunicación se realiza entre la aplicación bandeja y el gestor de items de trabajo, gracias al patrón Observador.
14. R-DBAS distribución asignando a un único recurso (Distribution By Allocation Single resource): El “workitems Manager” se puede configurar para que el workitem se asigne directamente a un recurso, sin ofrecérselo previamente. Se generará el evento que dispara la transición “s_allocate_s” en la red de recursos, se actualiza la tabla de workitems asignados (“HumanResourceAllocationHistory”) y se actualiza la bandeja del recurso.
15. R-RMA asignación aleatoria (RandoM Allocation): Indica una forma de ordenar los recursos candidatos. Se elegiría uno al azar.
16. R-RRA asignación circular (Round Robin Allocation): Expresa otra forma de ordenar los recursos candidatos. Se intenta que a todos los recursos se les asigne el mismo número de workitems. Es posible implementar esta forma de ordenación consultando la tabla de trabajos asignados (“HumanResourcesAllocationHistory”).
17. R-SHQ menor cola de trabajo (SHortest Queue): La tarea se asigna al recurso con menos trabajos asignados en su bandeja. De nuevo la información que mantiene el propio gestor de items de trabajo le permite seleccionar el recurso adecuado.
18. R-ED distribución temprana (Early Distribution): El diseñador del proceso puede indicar que una tarea concreta necesita distribución temprana. La red de recursos asociada a este tipo de tarea, se creará al iniciarse el caso. Para pasar a ejecución necesita que le llegue un evento indicando que el workitem puede continuar, porque llegó el momento de ejecutarse. Sin embargo el recurso asignado para ejecutarlo sabe con antelación que tiene que llevarlo a cabo más adelante y puede preparar todo lo necesario para ello, como por ejemplo reservar espacios, maquinaria, etc.
19. R-DE distribución al activarse (Distribution on Enablement): Esta es la forma normal de distribuir workitems a los recursos, cuando la red alcanza esta tarea se produce la gestión de recursos.
20. R-LD distribución tardía (Late Distribution): Los workitems se distribuyen en un momento posterior a su activación. El responsable de que esto ocurra será el WorkItems Manager. La causa que justifique esta situación puede ser que haya una sobrecarga de trabajo en el sistema, por ejemplo. Este patrón está relacionado también con el hecho de que se produzca un rebasamiento del tiempo máximo configurado para que un workitem permanezca ofrecido, sin ser asignado. En este caso habría que hacerse una redistribución del workitem para agilizar su ejecución.
21. R-RIA Asignación iniciada por el recurso (Resource-Initiated Allocation): Funcionalidad de la bandeja. Un recurso desde su aplicación de Worklist, viendo su lista de trabajos ofrecidos, puede seleccionar uno de ellos e indicar que se compromete a ejecutarlo, es decir se lo asigna a él mismo. La bandeja enviará el evento a la red de recursos del workitem para que avance hasta el estado de “allocated”.
22. R-RIEA Ejecución iniciada por el recurso de un item asignado (Resource-Initiated Execution-Allocated item): Similar al anterior. En este caso desde la bandeja se indica que el recurso empieza a ejecutar el workitem seleccionado en la lista de workitems asignados, haciéndolo evolucionar hasta el estado de “started”
23. R-RIEO Ejecución iniciada por el recurso de un item ofrecido (Resource-Initiated Execution-Offered item): Similar al anterior. En este caso desde la bandeja se indica que el recurso empieza a ejecutar el workitem seleccionado en la lista de workitems ofrecidos, haciéndolo evolucionar hasta el estado de “started”
24. R-OBS Contenido de la cola de trabajo determinado por el sistema (System Determined Work Queue Content): El Workitems Manager se puede configurar para que ordene según diferentes criterios la lista de workitems asignados presentada al recurso en su bandeja.
25. R-OBR Contenido de la cola de trabajo determinado por el recurso (Resource Determined Work Queue Content): En la aplicación Worklist se permite al recurso que ordene su lista de workitems asignados para determinar la secuencia en la que serán ejecutados.
26. R-SA Autonomía en la Selección (Selection autonomy): Como funcionalidad de la bandeja se permite al recurso cualquiera de los que tenga en la lista de asignados para indicar que empezará a ejecutarlo.
27. R-D Delegación (Delegation): En la aplicación bandeja se permite que el recurso indique que quiere delegar un determinado workitem, entonces el workitems manager calcula la lista de recursos candidatos a ejecutar dicha tarea, consultando la definición del proceso y de la tarea. Además, consultando al ResourcesManager calcula la lista de recursos en los que se le permite delegar al recurso en cuestión. Al final enviará a la bandeja el conjunto de recursos formado por la intersección de las dos listas calculadas, es decir, aquellos que satisfacen las restricciones indicadas en la definición del proceso y las delegaciones permitidas. El recurso en la bandeja elige aquel sobre el que quiere delegar dicho workitem. Esta delegación se añadirá a una tabla “DelegationsHistory” y se actualiza el registro correspondiente de la tabla “HumanResourceAllocationHistory”
28. R-E Escalada (Escalada): El gestor de Workitems puede ser configurado para que si se dan ciertas condiciones, como sobrepasar ciertos plazos, desequilibrio de la carga de trabajo o por políticas de la organización se le permita reasignar un workitem previamente asignado/ofrecido a otro recurso/s. Se enviará el evento adecuado dependiendo del estado actual del workitem (ofrecido, asignado, comenzado) y de si pasa a ofrecido o a asignado.
29. R-SD Desasignación (Deallocation): Como funcionalidad de la bandeja se ofrece al recurso la posibilidad de rechazar un workitem que tenía asignado. El Workitems Manager es el encargado de la reasignación u ofrecimiento a otro/s recursos. Debe asegurarse que los recursos elegidos no incluyan al que acaba de hacer la desasignación, comprobando en la tabla HumanResourceAllocationHistory, que ese workitem no estuviese previamente asignado a él. Un campo de esta tabla indicará si una asignación ha sido desasignada.
30. R-PR Reasignación con estado (Statefull Reallocation): Desde la bandeja se permite al recurso reasignar un workitem que estaba comenzado a otro recurso. Se implementa de forma similar a la delegación pero desde el estado de ejecutándose. El mantenimiento de los datos de la ejecución parcial del workitem se realiza a través de los datos del caso.
31. R-UR Reasignación sin estado (Stateless Reallocation): Este patrón solo se puede implementar para workitems capaces de ser rehechos sin ninguna consecuencia debida a la parte realizada anteriormente por el otro recurso. En estas condiciones la implementación del patrón es la misma que la de la reasignación con estado, puesto que no hay estado.
32. R-SR Suspensión/Reanudación(Suspension/Resumption ): Desde la bandeja un recurso puede suspender y reanudar un workitem. Si un workitem está suspendido por un recurso, podría ser reanudado por el mismo y ademas por cualquier otro recurso que tenga acceso al mismo, por estar en su grupo de trabajo, por ejemplo.
33. R-SK Salto (SKip): Desde la definición del proceso se pueden marcar las tareas que pueden saltarse (marcar el workitem como completado, aunque no se haya realizado realmente) porque no repercuta en los datos manejados por las tareas siguientes. Por defecto no se podrá saltar una tarea y si se quiere permitir esta funcionalidad se indicara en la definición de la tarea con la característica “canSkip”.
34. R-REDO Rehacer (REDO): El modelo planteado no permite rehacer workitems que ya han sido completados, puesto que supondría eliminar las marcas que están en la red en lugares posteriores al workitem que se va a rehacer.
35. R-PRE Hacer antes (PRE-do):Solo se permitirá hacer antes de tiempo workitems que no dependan de datos que puedan ser calculados posteriormente a la realización de los mismos. Se podrá marcar las tareas que puedan realizarse antes de tiempo, indicando en la definición la característica “canPreDo”.
36. R-CC Comenzar al crearse (Commence on Creation): En el momento de su creación se selecciona el recurso que deberá ejecutarlo y se le asigna pasando directamente a en ejecución. Se debe indicar en la definición con la característica “commenceOnCreation”.
37. R-CA Comenzar al asignarse (Commence on Allocation): Se implementa de igual forma al patrón anterior, en la definición del proceso se indicará mediante la característica “commence_On_Allocation”.
38. R-PE Ejecución en Pila (Piled Execution): En la definición de un proceso se puede indicar qué recurso/s serán manejadores de una tarea concreta. Cuando un workitem de esa tarea se complete, si el recurso que la ejecutó es manejador de esa tarea, el sistema enviará un evento a su bandeja para que pase a ejecución el siguiente workitem de esa tarea, con lo que se obtiene una mejora del tiempo de respuesta.
39. R-CA Ejecución en cadena (Chained Execution): Se acelera el tiempo de respuesta del caso cuando los workitems del mismo se realizan secuencialmente y por el mismo recurso. Se puede marcar una tarea con ChainedExecution=true, para indicar que esta tarea está encadenada con la siguiente, de manera que, cuando se complete dicha tarea se asignará la siguiente tarea al mismo recurso y se pasará automáticamente al estado ejecutándose. Si todas las tareas de un proceso se ejecutan en cadena, se puede indicar en la definición del proceso y no hará falta especificarlo tarea por tarea.
40. R-CUWIV (Configurable Unallocated Work Item Visibility): Siempre y cuando sus privilegios se lo permitan, un recurso desde su bandeja puede solicitar ver la lista de todos los workitems creados que todavía no han sido asignados, indicando si han sido ofrecidos a algún recurso o no.
41. R-CAWIV (Configurable Allocated Work Item Visibility): Lo mismo que en el patrón anterior, un recurso desde su bandeja puede solicitar diferentes consultas sobre workitems asignados, como por ejemplo, ver la lista de workitems asignados a recursos con un role determinado.
42. R-SE Ejecución simultanea (Simultaneous Execution): En el sistema descrito se permite a un recurso tener en ejecución varios workítems a la vez.
43. R-AR Recursos adicionales (Aditional Resources): En el sistema descrito no se permite a un recurso que está ejecutando un workitem solicitar ayuda a otros recursos.

Tabla de patrones

A continuación, se indicará el grado de cumplimiento de cada patrón en el sistema descrito.

Patrón	Soporte	Comentarios
DA	Total	Mediante expresiones
RBA	Total	Mediante expresiones
FBA	Total	Mediante expresiones
RA	Total	Mediante expresiones que consultan datos del modelo organizacional
SOD	Total	Mediante listas de tareas incompatibles en cuanto a recursos para un mismo caso
CH	Total	Se encargará el gestor de ítems de trabajo
RF	Total	Mediante expresiones
CBA	Total	Mediante expresiones que consultan datos del modelo organizacional
HBA	Total	Mediante expresiones que consultan el historial de ejecuciones
OA	Total	Mediante expresiones que consultan los datos del modelo organizacional.
AE	Total	No necesita implementación.
DBOS	Total	El gestor de items de trabajo se puede configurar para que el workitem se ofrezca solamente a un candidato de la lista de candidatos obtenida.
DBOM	Total	El gestor de items de trabajo se puede configurar para que el workitem se ofrezca a todos los candidatos de la lista obtenida.
DBAS	Total	El gestor de ítems de trabajo se puede configurar para que el workitem se asigne directamente al recurso seleccionado, sin necesidad de ofrecerselo previamente.
RMA	Total	Configuración del gestor de recursos
RRA	Total	Configuración del gestor de recursos
SHQ	Total	Configuración del gestor de recursos
ED	Total	La red de recursos de tareas con distribución temprana se crean al iniciarse el caso, y avanza como máximo hasta la asignación del workitem a un recurso. Cuando llegue el token a esta tarea podrá pasar a ejecución.
DE	Total	Distribución habitual de los workitems.
LD	Total	Funcionalidad del gestor de items de trabajo
RIA	Total	Funcionalidad de la aplicación bandeja de recursos.
RIEA	Total	Funcionalidad de la aplicación bandeja de recursos.
RIEO	Total	Funcionalidad de la aplicación bandeja de recursos.
OBS	Total	Configuración del gestor de items de trabajo.
OBR	Total	Funcionalidad de la aplicación bandeja de recursos.
SA	Total	Funcionalidad de la aplicación bandeja de recursos.
D	Total	Funcionalidad de la aplicación bandeja de recursos.
E	Total	Funcionalidad del gestor de items de trabajo.
SD	Total	Funcionalidad de la aplicación bandeja de recursos
PR	Total	Funcionalidad de la aplicación bandeja de recursos
UR	Parcial	Solo para workitems capaces de ser rehechos sin ninguna consecuencia para los workitems siguientes, debida a la parte realizada anteriormente por el otro recurso.
SR	Total	Funcionalidad de la aplicación bandeja de recursos
SK	Total	Expresándolo en la definición de la tarea en la definición del proceso.
REDO	Ninguno	No soportado por el sistema, ya que implicaría borrar marcas de la red de Petri asociada, y esto no es posible en sistema planteado.
PRE	Total	Expresándolo en la definición de la tarea en la definición del proceso.
CC	Total	Expresándolo en la definición de la tarea en la definición del proceso.
CA	Total	Expresándolo en la definición de la tarea en la definición del proceso.
PE	Total	Definiendo manejadores de la tarea en la definición. Estará encargado de llevar a cabo la ejecución en cadena el gestor de ítems de trabajo.
CA	Total	Expresándolo en la definición de la tarea en la definición del proceso.
CUWIV	Total	Funcionalidad de la bandeja de recursos comprobando además los permisos de acceso a la información del recurso que la solicita.
CAWIV	Total	Funcionalidad de la bandeja de recursos comprobando además los permisos de acceso a la información del recurso que la solicita.
SE	Total	Funcionamiento estándar del sistema.
AR	Ninguno	No soportado por el sistema, ya que no se permite la ejecución de un mismo workitem por más de un recurso simultáneamente.

Conclusiones

Como se puede apreciar en la tabla anterior mediante el sistema descrito se consigue implementar la gran mayoría de los patrones de recursos descritos en . Quedaría pendiente de considerar en el futuro, poder especificar que una tarea se debe llevar a cabo por X recursos pertenecientes a un grupo o que cumplan un determinado role. El gestor de workitems tendría que encargarse de dicha comprobación.

Referencias

• [1] F. Curbera, Y. Goland, J. Klein, et al. Business process execution language for web services, version 1.0. standards proposal by BEA Systems. Technical report, International Business Machines Corporation and MicroSoft Corporation, 2002.
• [2] Marlon Dumas, Will van der Aalst, and Arthur H.M. ter Hofstede. Process-Aware Information Systems. Bridging People and Software through Process Technology. John Wiley & Sons, 2005.
• [3] Grupo E-Force. TIDStateEngine - manual de usuario. Telefónica Investigación y Desarrollo, S.A. Unipersonal, 2.00 edition, June 2002.
• [4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Patrones de Diseño. Addison Wesley, 2002.
• [5] Claude Giralt and Rdiger Valk, editors. Petri Nets for Systems Engineering. Springer Verlag, 2003.
• [6] T.A. Halpin. Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design. Morgan Kaufmann Publishers, San Francisco, 2001.
• [7] R. Milner. Communicating and Mobile Systems: The Pi-Calculus. Cambridge University Press, Cambridge, UK, 1999.
• [8] N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource Patterns. BETA Working Paper Series, WP 127, Eindhoven University of Technology, Eindhoven, 2004
• [9] Morfeo Project. Morfeo project - home page. http://www.morfeo-project.org/
• [10] Michael Weber. Petri net markup language, 2006. http://www2.informatik.hu-berlin.de/top/pnml/pnml.html
• [11] WfMC. Wfmc xpdl resources, 2006. http://www.wfmc.org/standards/XPDL.htm
• [12] Kees van Hee Will van der Aalst. Workflow management. Models, Methods and Systems. The MIT Press, 2002.
• [13] W.M.P. van der Aalst. Pi calculus versus petri nets: Let us eat humble pie rather than further inflate the pi hype. BPTrends, 3(5):1–11, May 2005.