Tesis Workflow

Ci:1no i I:\i1io.cio: . i L1io A\.:z.
o
ii I:1i11o Ioii1ic:ico N.cio:.i
Deartanento de IngenIerIa EIctrIca
SeccIn de ConutacIn
AodeIado de vorkov con redes de IetrI
coIoreadas condIcIonaIes
TesIs que resenta
SanueI CarrIdo DanIeI
ara oLtener eI Crado de
Aaestro en CIencIas
en Ia EsecIaIIdad de
IngenIerIa EIctrIca
DIrector de Ia TesIs
Dra. XIaoou LI ZLang
AxIco, D.F. DIcIenLre 2005

ndice general
Dedicatoria V
Agradecimientos VII
Resumen IX
Abstract XI
1. Introduccin 1
1.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Descripcin del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Organizacin de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Tecnologa Workow 11
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Workow: Funciones y benecios . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Conceptos bsicos de Workow . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Sistemas administradores de workows . . . . . . . . . . . . . . . . . . . . . 17
2.4.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2. Modelo de Referencia de Workow . . . . . . . . . . . . . . . . . . . 19
2.5. Modelado de Workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ii NDICE GENERAL
2.5.1. Perspectivas de modelado . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.2. Tcnicas, lenguajes y herramientas de modelado de workow . . . . . 24
2.5.3. Redes de Petri para modelar Workows . . . . . . . . . . . . . . . . . 26
2.6. Comentarios nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3. Redes de Petri 29
3.1. Introduccin a las Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1. Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.2. Denicin formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.3. Representacin grca . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.4. Regla de disparo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.5. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.6. Propiedades y mtodos de anlisis . . . . . . . . . . . . . . . . . . . . 36
3.1.7. Extensiones de las redes de Petri bsicas . . . . . . . . . . . . . . . . 37
3.2. Red de Petri Coloreada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1. Denicin formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2. Marcado y regla de disparo . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3. Red de Petri Coloreada Condicional . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1. Denicin de Reglas ECA . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2. Representacin de una regla ECA con CCPN . . . . . . . . . . . . . 45
4. WfCCPN para modelado de procesos de workow 49
4.1. Por qu no utilizar CPN para modelar workow? . . . . . . . . . . . . . . . 49
4.2. Extensin a las redes de Petri coloreadas condicionales . . . . . . . . . . . . 51
4.3. WfCCPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1. Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.2. Reglas de disparo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.3. Denicin formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.4. Reglas ECA modeladas con WfCCPN . . . . . . . . . . . . . . . . . . 56
4.4. Representacin de conceptos bsicos de un workow . . . . . . . . . . . . . . 57
4.4.1. Procesos y casos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.2. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.3. Constructores bsicos de enrutamiento . . . . . . . . . . . . . . . . . 59
NDICE GENERAL iii
4.4.4. Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.5. Personas, Roles y Grupos . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.6. Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.7. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.8. Plazos y Caractersticas temporales . . . . . . . . . . . . . . . . . . . 62
4.4.9. Modelos jerrquicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.10. Mltiples instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5. Patrones de workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5.1. Patrones de ujo de control bsicos . . . . . . . . . . . . . . . . . . . 66
4.5.2. Ramicaciones y sincronizacin avanzada . . . . . . . . . . . . . . . . 67
4.5.3. Patrones estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.4. Patrones de mltiples instancias . . . . . . . . . . . . . . . . . . . . . 70
4.5.5. Patrones basados en estados . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.6. Patrones de cancelacin . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5.7. Patrones de workow en la perspectiva de datos . . . . . . . . . . . . 76
5. Implementacin 77
5.1. WfECAPNSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2. Diseo y arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.1. El componente visualizador . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.2. El componente administrador de modelos . . . . . . . . . . . . . . . . 80
5.2.3. Serializador de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.1. Edicin de WfCCPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3.2. Editor de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.3. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.4. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.5. Jerarqua y mltiples instancias . . . . . . . . . . . . . . . . . . . . . 90
5.3.6. Simulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.5. Sistemas de software relacionados . . . . . . . . . . . . . . . . . . . . . . . . 94
iv NDICE GENERAL
6. Metodologa y un caso de estudio 97
6.1. Metodologa propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.1.1. Identicar el proceso de workow . . . . . . . . . . . . . . . . . . . . 98
6.1.2. Representacin del proceso a travs de reglas ECA . . . . . . . . . . 98
6.1.3. Generacin de la WfCCPN y uso del WfECAPNSim . . . . . . . . . 101
6.2. Seleccin de artculos para un congreso cientco . . . . . . . . . . . . . . . . 101
6.2.1. Descripcin del workow . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.2. Modelo del proceso de workow . . . . . . . . . . . . . . . . . . . . . 103
6.2.3. Conjunto de Reglas ECA . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2.4. Conjunto de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.5. WfCCPN obtenida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7. Conclusiones 113
7.1. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Publicaciones 117
Dedicatoria
A ti pap, estos dos aos de mi estancia en el CINVESTAV han sido gracias al apoyo
incondicional y a la formacin que me has dado con tu ejemplo, el resultado de este trabajo
es tan tuyo como mo, al igual que este trabajo es tuyo mam por todo lo que eres para mi.
Tambin, dedico este trabajo a mis hermanos y a todos mis amigos y amigas con los
cuales he compartido diferentes etapas de mi vida.
vi
Agradecimientos
A Dios, por darme la vida y darme el camino que hasta hoy da he recorrido.
A mis padres, por todo el cario, amor, educacin, apoyo y ejemplo que me han brindado,
con lo cul he logrado todas las satisfacciones por las cuales hoy da, me siento orgulloso como
persona. A mis hermanos, por estar a mi lado.
A mi asesora la Dra. Xiaoou Li, por ste trabajo de tesis, por ser una excelente persona
y haberme brindado su apoyo en todo momento.
Al Dr. Joselito Medina Marin, por su amistad y ayuda valiosa en el desarrollo de mi
trabajo de tesis.
Al Dr. Francisco Rodrguez Henrquez y al Dr. Carlos Coello Coello, por sus valiosas
observaciones y comentarios respecto a la escritura de mi trabajo de tesis.
A Soa Reza, que desde siempre y hasta hoy da, me ha brindado su apoyo y amistad.
A los Doctores de la Seccin de Computacin, de quienes obtuve conocimientos de sus
cursos, en los que tuve la oportunidad de estar.
A todos mis compaeros de la Seccin de Computacin, en especial a mis Amigos: Dennis
Bazan, Roberto Linares, Efrn Clemente, Mario Parra, Juan Pablo Flores y Francisco Lpez ,
quienes compartieron conmigo situaciones difciles, pero tambin muchos logros y momentos
que quedarn en nuestras memorias de este captulo de nuestras vidas, que fu estudiar
nuestra Maestra.
Al CONACYT por apoyarme con la beca de maestra y al CINVESTAV.
viii
Resumen
El modelado de workow es un rea de investigacin que ha sido explorada por ms de
una dcada. Actualmente existen diversos trabajos en los que se emplean diferentes tcnicas
de modelado como son UML, IDEF0, redes de Petri, lgebras de procesos entre otras ms; sin
embargo actualmente no existe una metodologa o tcnica estndar. Un proceso de workow
es un proceso genrico de negocios, como ejemplos de estos procesos podemos citar la compra
en lnea de un libro, la inscripcin de un alumno al nuevo semestre escolar, la requisicin de
productos en un departamento de compras, entre otros ms. Es evidente que los procesos de
workow son procesos comunes que se encuentran en la vida diaria de toda organizacin o
empresa.
El atractivo de la tecnologa Workow, es la ejecucin de manera automatizada o semi-
automatizada de los procesos de negocio de una empresa, adems de permitir su administra-
cin y monitorizacin. Para estas tareas se utilizan los sistemas administradores de workows,
los cuales a partir de la denicin del proceso a travs de alguna tcnica de modelado, pueden
ejecutar dichos procesos en combinacin con otras tecnologas de informacin y del personal
humano involucrado.
Es as como la correcta especicacin del proceso asegurar en mayor medida la ejecu-
cin correcta del mismo. Las redes de Petri son una herramienta grca y matemtica para
modelado de sistemas. En la presente tesis se propone una metodologa basada en redes de
Petri para modelacin y simulacin de procesos de workow a travs de un enfoque de reglas
ECA (Evento-Condicin-Accin).
x
Abstract
Workow modeling is a research area that has been explored by more than one decade.
Currently, diverse research works have been proposed in which dierent techniques are used to
model it, such as UML, IDEF0, Petri nets, algebras of processes, among others. Nevertheless,
at the present time it does not exist a standard methodology or technique. A workow process
is a generic process of businesses. Examples of these processes are: the online purchase of a
book, the registration of a student to the new school term, a product requisition in a purchase
department, etc. It is evident that are processes that are present in the everyday life of every
organization or company.
The attractiveness of the Workow technology, is the execution of automated or semi-
automated forms of the business processes of a company, besides allowing to its administra-
tion and to monitor. In order to do these tasks, Workow Management Systems are used,
which (from the denition of the process through some modeling technique) can execute
these processes in combination with other information technologies and the involved human
resources.
Thus, the correct specication of the process will ensure in greater measurement the
correct process completion. Petri nets are a graphical and mathematical tool for systems
modeling. In the present thesis a methodology based in Petri nets for modeling and simulation
of workow processes through an approach based on ECA (Event-Condition-Action) rules is
proposed.
xii
Captulo 1
Introduccin
Con la incorporacin de la tecnologa como ayuda en las actividades del ser humano,
la forma de llevar a cabo stas ha cambiado y evolucionado de acuerdo a las necesidades
que se presentan en la vida diaria. Una de las direcciones de esta evolucin ha sido el in-
tento por automatizar las actividades cotidianas con ayuda de Tecnologas de Informacin
(Information Technologies. ITs; por sus siglas en ingls). Es as como las organizaciones
de diferentes sectores incorporan tecnologa para la realizacin de sus procesos con el n de
obtener dicha automatizacin y mejorar los resultados en sus procesos y objetivos de negocio.
Como consecuencia de lo anterior, las organizaciones actualmente poseen sistemas de infor-
macin con el n de organizar, automatizar y ejecutar sus procesos; de esta manera tenemos
que la tecnologa workow proporciona una plataforma para lograr dicha automatizacin de
procesos.
La tecnologa workow engloba diferentes conceptos, uno de los los principales es: el
proceso de workow, a continuacin se dene con el n de comprender de mejor manera
lo que esta tecnologa ofrece. Un proceso de workow, es un proceso genrico dentro de una
organizacin, como ejemplos de estos procesos podemos citar los siguientes: la compra en lnea
de un libro, la inscripcin de un alumno a un nuevo semestre, la requisicin de productos
en un departamento de compras, etc. Es evidente que los procesos de workow son procesos
comunes que se encuentran en la vida diaria y en las organizaciones, independientemente del
giro de stas. Aestos procesos comnmente se les reere como procesos de negocio; el atractivo
de la tecnologa workow, es la ejecucin de manera automatizada o semi automatizada de
esos procesos de negocio en las organizaciones. Para dicha tarea se emplean los Sistemas
Administradores de Workow (Workow Management Systems, WfMS), los cuales a partir
de la denicin del proceso de negocio realizada con alguna tcnica de modelado, llevan
2 Introduccin
a cabo la ejecucin del proceso conjuntamente a otras tecnologas de informacin y de las
personas que colaboran en la empresa.
Dentro del ciclo de vida de un WfMS se encuentra al inicio la fase de creacin y denicin,
seguida por las fases de vericacin y de representacin, concluyendo con la fase de ejecucin y
monitoreo del proceso. En esta tesis, el trabajo realizado se delimita dentro de la primera fase.
La tarea ms importante en esa primera fase es la modelacin de los procesos de workows
que ejecutar el WfMS. El modelado de workow consiste en la representacin y denicin
de los procesos de workow.
El modelado de workow
1
es un rea de investigacin que ha sido explorada y de la cual
existen diversos trabajos, en los que se emplean diferentes tcnicas (metodologas y lenguajes
de modelado) para modelar procesos de workow, como las siguientes: UML, IDEF0, redes
de Petri, lgebras de procesos, entre otras ms; sin embargo en la actualidad no existe una
tcnica estndar para esta tarea.
En este trabajo de tesis se aborda el tema de modelado de workow proponiendo una
metodologa basada en redes de Petri, as como un sistema de software que permita utilizar
esta metodologa para la denicin de dichos procesos, as como su simulacin a travs del
juego de tokens que proporcionan las redes de Petri. Actualmente existen diversos trabajos
relacionados con el tema, tanto en la industria como en el rea acadmica y de investigacin.
Estos trabajos son presentados a travs de un estudio del estado del arte sobre modelado de
workow.
1.1. Estado del arte
En los aos 90s surgi el trmino Workow dentro del rea de las ciencias computa-
cionales, y con l toda una serie de conceptos, herramientas de software, metodologas, traba-
jos de investigacin, estndares, organizaciones, entre otros elementos ms, sucientes para
que la Tecnologa Workow sea de gran importancia en la actualidad para la industria de
software y organizaciones que hacen uso de sta tecnologa. A continuacin se presenta el
estado del arte sobre el modelado de procesos workow.
1
En este trabajo se emplea la palabra en ingls workow para referirnos a procesos de negocios comnmente
conocidos como procesos de ujo de trabajo. Se usa la palabra en ingls debido a la aceptacin que tiene sta
y su uso extendido en la mayor parte de la literatura sobre el tema.
1.1 Estado del arte
3
La Coalicin para la Gestin de Flujo de Trabajo (Workow Management Coalition,
WfMC) es la principal organizacin en lo que se reere a workow y sistemas administradores
de Workows, la cual est conformada por instituciones acadmicas y comerciales. Actual-
mente, enfoca sus esfuerzos hacia una estandarizacin que permita lograr interoperabilidad
entre diferentes sistemas de workow que son desarrollados, adems de los que se encuentran
actualmente en el mercado y que actualmente se utilizan. En su trabajo se han obtenido
diversos resultados tales como el Modelo de Referencia de Workow [1]. En este modelo se
denen los conceptos y los elementos que debe poseer un sistema administrador de workow.
Todo trabajo relacionado con workow debera guiarse por el contenido de este modelo de
referencia. Adems, en el sitio web [2] se presentan diferentes reportes tcnicos en los que
publican sus estndares tales como XPDL y WfXML.
La Iniciativa para la Gestin de Procesos de Negocio (Business Process Management
Initiative, BPMI) es otra organizacin sin nimo de lucroque tiene la misin de promover el
desarrollo y uso de la administracin de procesos de negocio a travs del establecimiento de
estndares para el diseo, distribucin, ejecucin, mantenimiento y optimizacin de procesos.
Existen otros portales en Internet dedicados a la administracin de procesos de nego-
cios como por ejemplo: BPMG [3] (The Global Business Process Management Community),
ABPMP [4] (The Association of Business Process Management Professionals), el sitio web del
SIGPAM (Special Interest Group on Process Automation and Management) perteneciente
a la Asociacin de Sistemas de Informacin. El portal e-Workow [5]. Un buen sitio para
comenzar a investigar acerca de Workow es el Worfklow-Research [6] ya que adems de
proporcionar deniciones y conceptos, provee una seccin bastante completa de direcciones
web referentes a grupos de investigacin, investigadores, proyectos y productos de workow.
En la industria existen diversas compaas que mantienen bien posicionados sus WfMS
(Workow Management Systems). Ejemplos de stas son: Workow SAP R3, Lotus workow,
IBM MQSeries, Oracle Workow, entre otros ms. En software libre tambin existen WfMS
que son muy utilizados, como por ejemplo: jBPM, wfmOpen, OfBiz, OpenWFE, ObjectWeb
Bonita, Enhydra Shark.
.
Para el modelado de workow existen dos enfoques principales: UML (principalmente sus
diagramas de actividad) y redes de Petri. Con respecto a UML su principal desventaja es la
falta de bases formales, es decir de una semntica formal que permita la vericacin de los
4 Introduccin
modelos obtenidos a travs de tcnicas matemticas. El grupo Precise UML Group (PUML
2
)
trabaja en la claricacin y en direccin de obtener una semntica precisa para UML. Otros
trabajos de investigacin que existen se enfocan generalmente a desarrollar extensiones a
los diagramas de actividad o a obtener algoritmos que transformen procesos modelados con
diagramas de actividad en algn tipo de red de Petri con el objetivo de vericar el modelo
con alguna tcnica propia de redes de Petri. En [7], dos semnticas operacionales que utilizan
transiciones etiquetadas son propuestas para el modelado de workow utilizando diagramas
de actividad. Sin embargo, sta se encuentra desarrollada con la versin UML 1.4, esto es
considerado como una desventaja al existir actualmente la versin 2.0 de UML, y adems no
considera la perspectiva de datos. En [8], [9] son descritas las limitantes que la nueva versin
2.0 de UML que an presenta, a pesar de poseer bastantes mejoras, con lo que concluyen la
no total conveniencia de usar UML para el modelado de workow.
Por otro lado, algunos trabajos basados en extensiones o modicaciones de redes de
Petri son los siguientes: Renamiento de lugares con tokens de control usando redes predica-
do/transicin (Token controlled place renement using predicate/transition nets) [10], Redes
con referencias (Reference Nets) [11], Redes Jerrquicas de tareas con estado (Hierarchical
Task State Nets) [12], Redes workow (WfNets) [13], Redes reactivas (Reactive nets) [14],
entre otras ms. Sin lugar a dudas el trabajo ms completo es el realizado por Wil van der
Aalst y sus colaboradores, en el cual denen un nuevo lenguaje de workow llamado YAWL
[9]. YAWL toma las WfNets como punto de partida y aade constructores que no son de re-
des de Petri. Para el desarrollo del presente trabajo fueron tomadas algunas ideas de YAWL,
pero aadiendo elementos a las CCPN originales, es decir sin perder la estructura de red
de Petri. Los patrones de workow (Workow Patterns, WP) es otra de las investigaciones
del grupo de trabajo del profesor Aalst. Los WP son un conjunto de 20 patrones de ujo de
control que proveen un benchmark para comparar lenguajes para modelado de workow.
Los patrones de workow ms importantes que son identicados en la mayora de sis-
temas workow fueron reportados en el trabajo de tesis doctoral de Bartosz Kiepuszewsk
[15] en la Universidad de Queensland, Australia en colaboracin con W.V.D. Aalst. Estos
21 patrones se clasican en 6 grupos: Patrones de control bsico, Patrones de sincronizacin
y ramicacin avanzada, Patrones estructurales, Patrones que envuelven mltiples instan-
cias, Patrones basados en estados y Patrones de cancelacin. En este trabajo tambin se
encuentra una comparativa mediante un caso de estudio de las siguientes herramientas de
2
http://www.puml.org
1.2 Motivacin
5
Workow que existen actualmente en el mercado: FileNets Visual WorkFlo, Fort Conductor,
Changengine, Staware, Fujitsu i-Flow, MQSeries IBM Workow, Verve, SAP R/3 Workow.
En esta comparativa se aprecia cmo en algunos casos es imposible representar ciertas in-
stancias de un proceso, as como la diferencia en cuanto a simplicidad o complejidad en los
modelos obtenidos con cada una de las herramientas. Lo ms importante de esta comparativa
es el resultado en cuanto a soporte de los 21 patrones de workow, puesto que slo entre 9
y 11 patrones soportan en promedio cada uno de los sistemas de Workow analizados. Cabe
mencionar que son diferentes los patrones que soportan cada uno de esos sistemas [15], [16].
En el sitio Web del grupo de investigacin sobre Patrones de Workow [16], se han pub-
licado nuevos resultados del soporte que brindan otros productos de Workow importantes
como COSA, InConcert, Meteor, Mobile, entre otros, arrojando resultados similares a los
mencionados anteriormente. El mismo trabajo fue realizado para lenguajes de descripcin
de procesos que se utilizan para el modelado de Workow, tales como: XPDL, UML, BPEL
(conocido tambin como BPEL4WS), XLANG, WSFL, BPML y WSCI soportando entre 11
y 14 patrones cada uno de estos lenguajes.
Sobre redes de Petri es importante mencionar el grupo: Petri Nets World [17]; este grupo
est compuesto principalmente por investigadores de las Universidades de Aarhus en Dina-
marca y de Hamburgo en Alemania adems de investigadores de otras partes del mundo.
stos se encargan de concentrar todas las publicaciones, herramientas de software, grupos de
investigacin, estndares y referencias bibliogrcas sobre redes de Petri y temas relacionados
a stas. En cuanto a las CPNs, el grupo de redes de Petri Coloreadas [18] ms importante
se encuentra en la universidad de Aarhus, debido a que investigadores de esa universidad de-
sarrollaron esta extensin de las redes de Petri. Su trabajo ms importante es la herramienta
de software CPN-Tools la cual posee buena aceptacin en la industria para el modelado de
sistemas.
1.2. Motivacin
Un Workow es un sistema reactivo por naturaleza, ya que mantiene interaccin con
su ambiente durante su ejecucin [7]. Es decir un sistema reactivo corre en paralelo con el
ambiente e intenta hacer cumplir ciertos efectos deseables en el ambiente. Esto lo hace por
medio de reaccin a cambios en su ambiente, llamados eventos. La respuesta del sistema
6 Introduccin
reactivo depende de su estado interno actual. Dada una respuesta, el estado del sistema
reactivo puede cambiar [14].
El comportamiento de un sistema reactivo es modelado usualmente a travs de reglas ECA
(event-condition-action) [14]. Una regla E-C-A puede ser denida de la siguiente manera [7]:
Si el evento E ocurre y la condicin C es verdadera, entonces realizar la accin A
Una regla ECA simple, con un solo evento puede ser modelada como una red de Petri Col-
oreada. Sin embargo para eventos compuestos los cuales son ms complicados, los elementos
bsicos de una CPN no son sucientes [19]. Por esa razn, una modicacin de la CPN ha sido
propuesta en [19], [20] para representar estructuras de reglas ECA y su interrelacin. Siendo
as posible representar reglas ECA de manera ms natural. El nombre de esta propuesta es
Redes de Petri Coloreadas Condicionales (CCPN, por sus siglas en ingls).
En este trabajo se propone aplicar el enfoque de las CCPN para el modelado de procesos
de workow basados en el hecho de que son sistemas reactivos y su relacin con las reglas
ECA como enfoque para ser modelados. Para implementar la funcionalidad reactiva de los
eventos se utilizan las reglas EventoCondicinAccin (ECA), stas poseen una sintaxis
declarativa de alto nivel que permite una respuesta inmediata (reactiva). Las reglas ECA son
un tipo de reglas muy utilizadas en la gestin de bases de datos activas, aunque no estn
limitadas a ese campo de investigacin.
1.3. Planteamiento del problema
A pesar de que existen diversos enfoques para el modelado de procesos workow, ac-
tualmente no existe una metodologa grca estndar. Adems a travs de un marco de
trabajo de evaluacin conocido como patrones de workow, han sido sometidos los lenguajes
de modelado y herramientas de software para modelado de procesos workow ms utiliza-
dos e importantes en la actualidad. En investigaciones tales como [15], [9], [8] se presentan
resultados y conclusiones que muestran que ninguno de los lenguajes y sistemas estudiados
modela todas las posibles situaciones que pueden encontrarse en un proceso de workow y
que son representadas a travs de patrones de workow.
1.4 Objetivos 7
Una consecuencia de lo anterior, se presenta cuando el modelo de un sistema deja de ser
un modelo pequeo, tiende a ser muy complejo mantener la perspectiva de lo modelado (prin-
cipalmente de manera visual). Adems cuando se trata de enfoques basados en gramticas
sin parte grca resulta menos intuitivo. La importancia de la denicin del proceso de work-
ow radica en que en base al modelo obtenido se realiza la ejecucin del proceso de manera
automatizada con el WfMS. Es as como la correcta especicacin del proceso asegurar en
mayor medida la ejecucin correcta de ste.
1.4. Objetivos
Los objetivos que se pretenden alcanzar con este trabajo se dividen en un objetivo general
y en objetivos especcos.
1.4.1. Objetivo general
Proponer una metodologa para modelado de procesos workow basada en redes de
Petri, con lo cual se tendr una perspectiva formal y una grca del proceso modelado; la
metodologa propuesta tendr un enfoque de reglas ECA al utilizar redes de Petri coloreadas
condicionales (CCPN).
1.4.2. Objetivos especcos
Plantear el modelo de CCPN que proporcione los elementos necesarios para modelar
los conceptos que se encuentran presentes en la mayora de los procesos de workow.
Mediante un marco de trabajo realizar una evaluacin de la metodologa propuesta y
obtener los resultados correspondientes.
Implementar un sistema de software que permita modelar y simular procesos de work-
ow utilizando la metodologa obtenida.
A travs de un caso de estudio utilizar la metodologa para modelar procesos de work-
ow utilizando el sistema de software implementado, de tal manera que permita obtener
conclusiones sobre los benecios y las limitantes, as como probar la viabilidad del tra-
bajo realizado.
8 Introduccin
1.5. Descripcin del trabajo
Para el desarrollo de este trabajo de tesis, se realizaron las siguientes actividades: Como
primera tarea se realiz una investigacin sobre el rea de Workow, la cual permiti conocer
los conceptos y los temas relacionados a la tecnologa Workow; de igual forma se realiz el
estudio sobre redes de Petri. Posteriormente se llev a cabo el estudio sobre el modelado de
workow que permiti conocer los trabajos relacionados al tema que han sido reportados en
la literatura. Con el conocimiento de los trabajos sobre modelado de workow se obtuvo una
amplia referencia utilizada al momento de plantear nuestra metodologa. Adems, se utiliz
el estudio realizado con nes de evaluacin y comparacin.
Posteriormente, con el desarrollo de la metodologa se obtuvo una modicacin de las
CCPN originales utilizadas en [20], [19]. Esta modicacin se denomin Redes de Petri Co-
loreadas Condicionales para Workow (Workow Conditional Colored Petri Nets, WfCCPN
por sus siglas en ingls) con el n de diferenciar los trabajos realizados en el contexto de
bases de datos activas. Con la modicacin de algunas deniciones y la incorporacin de
nuevos elementos, se modelaron los conceptos de workow que son denidos en el modelo
de referencia de la WfMC en [21]. Con los conceptos modelados fue posible llevar a cabo la
implementacin de los veinte patrones de workow denidos dentro del marco de evaluacin
(evaluation framework) conocido como patrones de workow (workow patterns
3
), obtenien-
do resultados satisfactorios ya que fue posible la implementacin de todos ellos utilizando
WfCCPN.
Al nalizarse las etapas anteriores fue posible iniciar el desarrollo del sistema de software.
La implementacin fue realizada tomando como base el sistema ECAPNSim desarrollado
para el modelado de reglas ECA en bases de datos activas [19]. Se realiz una modicacin
y extensin en general de todo el sistema, aadiendo diversas caractersticas no consideradas
por el ECAPNSim. El sistema desarrollado fue denominado: Simulador de redes de Petri-
ECA para workow (Workow ECA Petri Net Simulator), el cual es referido a lo largo de
este trabajo por sus siglas en ingls: WfECAPNSim.
Finalmente, se realiz la modelacin de dos casos de estudio utilizando la metodologa y
el sistema de software obtenidos para efectos de vericacin, validacin, as como de com-
paracin con trabajos relacionados. El trabajo realizado se reporta en el presente documento
de tesis.
3
http://www.workowpatterns.com
1.6 Organizacin de la tesis 9
1.5.1. Contribuciones
Las contribuciones que se ofrecen con el trabajo realizado son las siguientes:
Un modelo extendido de las CCPN para el modelar procesos de workow, denominado
WfCCPN, ampliando as las reas de utilizacin de las CCPN.
Una metodologa para la denicin y simulacin de procesos workow utilizando las
WfCCPN. sta ofrece elementos que permiten modelar aspectos que no son posibles
de modelar con las redes de Petri coloreadas, La metodologa se diseo de forma que
sta resultara lo ms intuitiva y fcil de utilizar para usuarios con y sin experiencia en
el uso de redes de Petri, esto se obtuvo gracias a los diversos tipos de elementos de la
WfCCPN.
Un sistema de software para el uso de las WfCCPN implementado en lenguaje Java
el cual ofrece caractersticas que no son comunes de encontrar en sistemas de software
para modelado de workow gratuitos. El sistema WfECAPNSim puede ser considerado
para futuros trabajos sobre representacin y ejecucin de workow.
1.6. Organizacin de la tesis
La estructura de este trabajo fue dividida en 7 captulos, los cuales se encuentran orga-
nizados de la siguiente manera:
En el captulo 1, se presenta la investigacin realizada, sobre la que se fundamenta esta
tesis. sta consiste en un estudio sobre el estado del arte en cuanto al tema de modelado de
workow, tambin se proporciona la motivacin para el desarrollo de este trabajo de tesis, y
se plantea el problema sobre el cual se trabaja para obtener una propuesta de solucin a ste.
En el captulo 2, se muestra lo que es la tecnologa workow y el modelado de workow. En el
captulo 3, se proporciona la introduccin a los conceptos bsicos de redes de Petri, las redes
de Petri Coloreadas su denicin y utilidad, adems de presentar la denicin de una CCPN.
En el captulo 4 se expone la modicacin a las CCPN denominada WfCCPN y se describe la
manera en que los conceptos de workow son modelados utilizando la metodologa propuesta
basada en WfCCPN. Adems se muestra la implementacin de los patrones de workow
utilizando dicha metodologa. En el captulo 5, se presenta el desarrollo de software realizado.
10 Introduccin
El sistema implementado, que fue denominado WfECAPNSim es descrito en cuanto a su
arquitectura y diseo, as como en las caractersticas que posee. En el captulo 6, se expone
un caso de estudio modelado con la metodologa propuesta en esta tesis. Finalmente, en el
captulo 7 se presentan las conclusiones sobre los resultados obtenidos, adems del trabajo
futuro que puede ser realizado al seguir sobre esta lnea de investigacin.
Captulo 2
Tecnologa Workow
2.1. Introduccin
En la dcada de los 90s surgi la tecnologa Workow
1
(Flujo de Trabajo
2
) en el contexto
de Sistemas de Informacin, como una nueva solucin para la administracin o gestin de
los procesos que se realizan dentro de una organizacin. Con el auge de Internet y de las
Tecnologas de Informacin, el Workow ha evolucionado de manera rpida y su uso se ha
incrementado en los negocios de diversas industrias. Su caracterstica principal es la automati-
zacin de procesos organizacionales (conocidos tambin como procesos de negocio), los cuales
integran por lo general una combinacin de personas y actividades basadas en mquinas, que
adems, en su realizacin interactan con aplicaciones de software y tecnologas de informa-
cin.
La evolucin de los sistemas de informacin puede verse por etapas. En [13] se presenta
la siguiente retrospectiva:
1975-1985 Administradores de bases de datos.
1985-1995 Administracin de interfaces de usuario.
1995-2005 Administracin de workows.
En la primera etapa, con los sistemas administradores de bases de datos, se tuvo la exis-
tencia de diversos sistemas de informacin en los cuales se manejaba y administraba toda la
1
En esta tesis, la tecnologa Workow ser referida simplemente como Workow.
2
Flujo de trabajo es la traduccin en espaol de workow. Sin embargo, en esta tesis se utiliza la palabra
en ingls debido a la aceptacin que sta tiene en la literatura.
12 Tecnologa Workow
informacin necesaria para llevar a cabo la produccin en las empresas. Se lograron autom-
atizar tareas, que antes eran realizadas manualmente. Sin embargo, en las siguientes etapas
surgi la necesidad de mejorar el ujo de la informacin, y de obtener la informacin de man-
era rpida y eciente, adems de optimizar la productividad, acortar tiempos en la realizacin
de los procesos, tener control sobre stos, con el n de reducir costos y mejorar la gestin en
la organizacin. Como consecuencia a lo anterior, hubo un incremento en la competitividad
organizacional, que actualmente tambin es resultado de la globalizacin que sucede en el
mundo. En la segunda etapa, con la administracin de interfaces de usuario se logr mayor
facilidad de utilizacin de los sistemas para usuarios nales, gracias a interfaces de usuario
cada vez ms interactivas y menos susceptibles de aceptar errores humanos. Esto permiti la
proliferacin de los sistemas de informacin basados en computadoras, al ser ms accesibles
en cuanto a utilizacin para las personas en general. Finalmente, en la tercera etapa se tiene
la administracin de workows, la cual ayuda en la administracin del control y ejecucin de
procesos de negocio en las organizaciones.
Para entender mejor la tercer etapa en la evolucin de sistemas de informacin, es nece-
sario denir lo que signica un proceso de negocio, el Workow Management Coalition
(WfMC) principal organizacin en el mundo sobre el tema de Workow lo dene de la siguien-
te manera: un proceso de negocio es el conjunto de uno o ms procedimientos o actividades
directamente ligadas, que colectivamente realizan un objetivo del negocio, normalmente, lo an-
terior es dentro del contexto de una estructura organizacional que dene roles funcionales y
relaciones entre los mismos [21]. Tambin es necesario denir el trmino workow, el WfMC
lo dene como: la automatizacin computarizada de un Proceso de Negocio, de manera total
o parcial, en la cual documentos, informacin o tareas son pasadas de un participante a otro
para efectos de su procesamiento. Lo anterior se realiza de acuerdo a un conjunto de reglas
establecidas [21].
La administracin de workows no es una solucin que se implementa nicamente con la
instalacin de un programa de software para despus esperar la obtencin de resultados de
forma inmediata; por el contrario, una solucin de este tipo representa el tener tecnologas de
informacin, sistemas de software, polticas organizacionales, cooperacin de los empleados de
la empresa, entre otros elementos ms que trabajan de acuerdo a la implementacin necesaria
para automatizar los procesos de negocio de la empresa; adems, para la implementacin se
requiere de un anlisis de la forma en que se realizan actualmente los procesos y en ciertos
casos es necesario la aplicacin de re-ingeniera en los procesos, lo que signica volver a
2.2 Workow: Funciones y benecios 13
plantear la manera en que stos se realizan con el n de mejorar. Entre los sistemas de software
necesarios, se encuentra una componente principal para la implementacin de una solucin
basada en workow, que es el Sistema Administrador de Workow (Workow Management
System, WfMS por sus siglas en ingls), este tipo de sistemas son estudiados en la siguiente
seccin, antes de ello se remarcan a continuacin las principales funciones y benecios que
ofrece la implementacin del Workow en una organizacin.
2.2. Workow: Funciones y benecios
Las funciones ms comunes que realiza un workow son:
Asignacin de tareas al personal.
Aviso al personal de tareas pendientes.
Permitir la colaboracin en las tareas comunes.
Optimizacin de recursos humanos y tcnicos alinendolos a la estrategia de la empresa.
Automatizacin de las secuencias de los procesos de negocio y optimizacin de las
mismas.
Agilizacin de los procesos de negocio y dando por resultado, un mejor servicio al
cliente.
Control y seguimiento de dichos procesos.
Modicacin de instancias de procesos sobre la marcha.
Las funciones citadas anteriormente reditan en diversos benecios a la organizacin, stos
han convertido al Workow en una tecnologa vital dentro los negocios de organizaciones
actuales. Algunos de los benecios ms importantes son:
Mejora en servicio y atencin al cliente.
Incremento en la ejecucin de actividades en paralelo.
Minimizacin en el tiempo para acceso a documentacin, aplicaciones y bases de datos.
14 Tecnologa Workow
Disminucin del tiempo de transferencia de informacin entre tareas.
Se asegura la completa colaboracin del personal de trabajo.
Permite tener conocimiento inmediato del estado de alguna tarea o proceso.
Mejora en la gestin y optimizacin de procesos.
De lo anterior, lo ms especico de la tecnologa de workows es el Sistema Administrador
de Workows (WfMS). En la siguiente seccin se proporciona una denicin y las funciones
de este tipo de sistemas, adems de su arquitectura, la cual actualmente se encuentra es-
tandarizada.
2.3. Conceptos bsicos de Workow
En el modelo de referencia del WfMC se establecen los conceptos que forman parte de
la tecnologa Workow, tanto de un proceso de workow como de los sistemas de workow.
Es preciso mencionar que en esta tesis nos referiremos al proceso de negocio como proceso
de workow y a los sistemas de workow como WfMS. Los conceptos ms importantes que
forman un proceso de workow son los siguientes: Caso, Proceso, Tarea, Enrutamiento, Datos,
Personas, Roles, Grupos, Eventos, Plazos. Antes de presentar la arquitectura y funciones un
WfMS, se proporciona una breve denicin de los conceptos del proceso de workow.
Caso. Es un elemento fsico o abstracto el cual es producido o modicado por algn tipo
de trabajo, los siguientes son sinnimos de un caso: Trabajo, Job, Producto, Servicio, Item.
Un caso siempre tiene un inicio y un n.
Proceso. Un proceso consiste de un nmero de tareas que necesitan ser realizadas y un
conjunto de condiciones que determinan el orden de las tareas.
Tarea. Las tareas son unidades de trabajo formadas por un conjunto de acciones o ac-
tividades, que son realizadas por uno o ms recursos (un recurso puede ser una persona o una
mquina) en un intervalo de tiempo predeterminado. Una tarea es atmica, lo cul quiere
decir que no es divisible en tareas ms pequeas [22]. Es importante este concepto de tarea
ya que para la fase de modelado es necesario tener previamente identicadas las tareas, esto
se logra a travs del anlisis del proceso como un ujo de trabajo. Podemos considerar los
2.3 Conceptos bsicos de Workow
15
siguientes ejemplos de tareas: evaluar un reporte, calicar un examen, llenar un formato,
contestar una llamada telefnica.
Las tareas pueden ser manuales, automticas y semiautomticas. Las tareas manuales son
realizadas exclusivamente por personas. Por el contrario en una tarea automtica en la que
no existe participacin alguna de personas. Mientras que, en las tareas semiautomticas, se
tiene una combinacin de las dos anteriores.
Enrutamiento. En un proceso de workow la informacin uye a travs de los distintos
elementos que conforman el proceso. Es as como la informacin puede tomar diferentes
rutas hasta llegar a completarse. Lo anterior es conocido como ujo de control del workow;
para representar esas posibles rutas se han denido los siguientes constructores bsicos en el
modelo de referencia de workow de la WfMC.
AND-Split. Es un punto del workow en donde un simple hilo de control
3
se divide en
dos o ms hilos, los cuales son ejecutados en paralelo dentro del workow. Es decir, a travs
de cada uno de ellos puede uir informacin en un mismo instante permitiendo que mlti-
ples actividades sean realizadas simultneamente. Cada AND-Split debe ser complementado
con un AND-Join. En algunos sistemas un AND-Join recibir hilos que pueden arribar de
diferentes AND-Split [23].
OR-Split. Es un punto en el workow donde al nal de un nico hilo de control se toma
una decisin con la cual se bifurcar cuando se encuentra con mltiples alternativas.
AND-Join. Es un punto en el workow donde dos o ms actividades que se ejecutan
en forma paralela convergen, entonces gracias a esa convergencia, otra actividad puede ser
iniciada [23].
OR-Join. Es un punto en el workow donde dos o ms alternativas para continuar
dentro del workow re-convergen en una simple actividad como el siguiente paso a seguir en
el workow.
Datos. Los datos son los documentos, archivos, imgenes, registros de la Base de Datos,
y otros utilizados como informacin para llevar a cabo el trabajo. Entre los datos manejados
por el Workow encontramos:
3
La ruta que sigue la informacin de un elemento a otro se le conoce como hilo de control.
16 Tecnologa Workow
Datos de Control: son los datos internos manejados por la lgica del sistema de Work-
ow.
Datos Relevantes: son aquellos datos utilizados para determinar el ruteo de las distintas
tareas del sistema.
Datos de la Aplicacin: estos datos son especcos de la aplicacin, no son accedidos
por la lgica del Workow.
En cuanto a los datos, es muy utilizada la nocin de documento como recipiente de infor-
macin que se transmite de una tarea a otra. Por esta razn, cuando se hace referencia a datos
manejados por el sistema, es posible referirse a estos datos como documentos. Existen ciertas
propiedades que se le pueden asociar a un documento, tales como: la denicin de los derechos
de acceso a los mismos; las vistas denidas sobre ellos; manejo de accesos concurrentes (es
decir, que dos personas o procesos puedan acceder al documento simultneamente); tambin
es posible denir formas de relacionar datos provenientes de fuentes externas al documento,
tales como datos de la aplicacin o de la base de datos.
Personas. Como se mencion anteriormente las tareas son realizadas por recursos ya
sean mquinas o seres humanos, es as como las personas dentro de una organizacin son
parte importante en lo que a cumplimiento de los procesos se reere. En muchos procesos las
tareas son realizadas en un orden establecido previamente por ciertas personas de acuerdo a
su capacidad o rol que desempee dentro de la empresa, adems de realizarse en base a las
condiciones y reglas de negocio. Una persona es conocida como un actor dentro del escenario
de un workow, sin embargo como actor tambin puede referirse a una mquina.
Roles. Cada rol dene las distintas competencias potenciales que existen en el sistema.
Se denen independientemente de las personas fsicas a las cuales se les van a asignar dichos
roles. Una persona puede tener ms de un rol, siendo un rol un conjunto de caractersticas de
un actor. En el caso de actores personas, un rol se puede referir a determinadas habilidades,
responsabilidades o autoridad que sta posea.
Grupos Es un conjunto de actores que realizan el mismo rol. Cuando se asignan tareas a
un grupo de actores en vez de a un solo actor, se puede tener mayor exibilidad en la seleccin
de quien puede realizar la tarea, teniendo as una divisin de las labores ms eciente [7].
Eventos. Un evento es una interrupcin que contiene informacin, ste tiene un origen y
2.4 Sistemas administradores de workows
17
uno o ms destinatarios. La informacin contenida en el mensaje que se produjo por el evento
puede ser implcita o dada por el usuario. Los eventos pueden ser disparados voluntariamente
por el usuario; o en forma implcita durante un proceso segn el estado de los datos o de
decisiones tomadas por el usuario; o en forma automtica. Por ejemplo, cuando un gerente
de un banco hace una consulta sobre ciertos datos para hacer una auditoria, se dispara un
evento que le devuelve la informacin sobre dicha consulta.
Plazos. Son los tiempos que se le asignan a ciertas tareas para que stas sean realizadas
o esten listas antes de tomar una determinacin diferente a la normal, como podra ser su
cancelacin o la nalizacin del proceso mismo. Podemos considerar los siguientes ejemplos
de plazos: el tiempo mximo que se le asigna a una tarea para que sea terminada, el tiempo
mximo para recorrer una ruta; terminar una tarea antes de cierta fecha, entre otras ms.
A los plazos podemos asignarles eventos, de forma que con el incumplimiento del plazo se
dispare dicho evento de forma automtica.
2.4. Sistemas administradores de workows
En las secciones anteriores se present el concepto de lo que es un proceso de workow,
as como los conceptos que lo conforman. Tambin fue dada una breve denicin de lo que es
un sistema el cual ejecuta y administra procesos workow, este tipo de sistemas se conocen
como WfMS. En esta seccin se describen las caractersticas y arquitectura de los WfMS de
acuerdo al modelo de referencia de la WfMC.
2.4.1. Caractersticas
En su nivel ms alto todos los WfMS proveen soporte en tres reas funcionales:
Las funciones en tiempo de diseo (Build-Time) relacionadas con la denicin y mode-
lado de cada proceso y actividades que le constituyen.
Las funciones de control en tiempo de ejecucin (Run-Time) relacionadas con la ad-
ministracin del proceso de workow en un ambiente operacional y secuenciando las
diversas actividades a ser mejoradas como parte de cada proceso.
18 Tecnologa Workow
Definicin y diseo
de procesos
Tiempo de diseo
Tiempo de ejecucin
Instanciador y
control de procesos
Interaccin con
usuarios y
aplicaciones de
software
Anlisis, Modelado y Herramientas
de definicin
Definicin de procesos
Cambios en los
procesos
Servicio de representacin
del Workflow
Aplicaciones y
herramientas
Usuarios
Figura 2.1: Caractersticas de un workow
19
Las interacciones en tiempo de ejecucin entre personas, aplicaciones y tecnologas de
informacin.
Estas caractersticas son reejadas en los mdulos o componentes que forman la arqui-
tectura de un WfMS, las cuales se describen a continuacin.
2.4.2. Modelo de Referencia de Workow
La proliferacin de los WfMS en el mercado de software y los diferentes enfoques por parte
de cada una de las compaas desarrolladoras de este tipo de sistemas, adems de una cada
vez mayor necesidad de interactuar y compartir informacin entre organizaciones, develaron
el problema de la interoperabilidad entre este tipo de sistemas. Es por ello que en 1992
se crea la Coalicin para la administracin de workow (Workow Managament Coalition,
WfMC [2]), la cual se conforma por compaas de software, instituciones acadmicas y de
investigacin. Uno de sus primeros trabajos fue establecer una arquitectura de referencia
para los WfMS, pensado para la adaptacin de sistemas ya existentes, as tambin para los
nuevos desarrollos, con el n de lograr la interoperabilidad deseada. El Modelo de Referencia
de Workow (Workow Reference Model) [21] fue presentado en su primera versin en 1994,
habiendo muy pocas modicaciones a partir de su elaboracin a la fecha. La gura 2.2 muestra
la arquitectura para un WfMS sugerida en el modelo de referencia de workow.
A continuacin se describe la forma en cmo interactan los elementos que componen un
WfMS de acuerdo al modelo de referencia de la WfMC contenido en [21].
Herramienta para denicin de procesos de workow
Este componente y la interfaz 1 se describen a continuacin con ms detalle que el resto
de los componentes debido a que el proyecto realizado en esta tesis se enfoca en el modelado
de procesos de workow, actividad que se lleva a cabo gracias a este componente.
La herramienta para la denicin de procesos, permite modelar, describir y documentar
un proceso de workow. Para esta tarea existen lenguajes y mtodos de modelado para
procesos de workow, los cuales se basan en diferentes enfoques, como pueden ser: redes de
Petri, UML (Unied Modeling Language), mquinas de estado nito, diagramas de ujo,
entre otros ms.
20 Tecnologa Workow
Herramienta para la
administracin y
monitoreo de los
procesos
Aplicaciones clientes
(usuarios del WfMS)
Aplicaciones
invocadas (software
que interacta con el
WfMS)
Herramienta para la
definicin de
procesos
Workflow API y formatos para el intercambio
de datos
Otros workflow
Motor(es) de
Workflow
Motor(es)
de
Workflow
Interfaz 5
Interfaz 2 Interfaz 3
Interfaz 1
Interfaz 4
Figura 2.2: Modelo de referencia para un sistema administrador de workow.
La denicin de procesos se realiza modelando los conceptos de la vida real a travs de
los elementos que proporciona el lenguaje de modelado que sea utilizado. Preferentemente el
proceso de workow debe ser modelado de acuerdo a los conceptos que han sido denidos
por el WfMC, los cuales se encuentran en [21].
La salida de este proceso de modelado y diseo es una denicin de procesos la cual
puede ser interpretada va la interfaz 1 en tiempo de ejecucin por el motor(es) de Workow
a travs del Servicio de representacin. La interfaz 1 permite la comunicacin entre ste y el
componente de representacin de workow.
El Servicio de representacin de workows es el componente central encargado de inter-
pretar la descripcin de procesos realizada con la Herramienta para denicin de procesos,
adems de controlar las diferentes instancias de procesos, administrar las secuencias de ac-
tividades, aadir elementos a la lista de trabajo de usuarios e invocar aplicaciones necesarias.
Todas estas tareas son hechas por uno o ms motores de Workow, los cuales manejan la
ejecucin de las distintas instancias de los procesos. El motor de workow es el software que
21
provee el control del ambiente de ejecucin de una instancia de Workow. En caso de estar en
un entorno distribuido, pueden existir otros componentes de representacin de workow con
sus respectivos motores de workow. La comunicacin con stos se logra a travs de la inter-
faz 4. El componente Workow WAPI y formatos para el intercambio, permite la interaccin
del servicio de representacin de workow con el resto de los componentes, proporcionando
datos entendibles para cada uno de los componentes.
Aplicaciones cliente
Este componente representa los programas de software utilizados por el usuario nal del
WfMS en las actividades que requieren participacin humana. La interfaz 2 permite denir
y manejar las listas de trabajo que se encuentran en los motores de workow. Una lista
de trabajo es una lista asignada que contiene actividades por hacer, trabajos pendientes,
recordatorios entre otras, las cuales deben ser ejecutados por un usuario o grupo de usuarios.
Aplicaciones invocadas
Este componente representa todo el software existente dentro de la organizacin, el cual
es utilizado por el WfMS con el n de interactuar y realizar ciertas actividades. Estas apli-
caciones de software pueden encontrarse en cualquier lugar dentro de la red de trabajo, un
ejemplo es el software administrador de correos electrnicos. La interfaz 3 permite la co-
municacin entre este componente y el de representacin de workow a nivel de invocacin,
transformacin y representacin de datos, de manera que stos sean entendibles para el motor
de workow.
Herramienta para administracin y monitoreo
El componente Herramienta para administracin y monitoreo y la interfaz 5 tienen como
propsito permitir una vista completa del estado del workow. Adems, con ste es posible
realizar auditoras sobre los datos del sistema. Esta herramienta es utilizada por el admin-
istrador del WfMS y por los altos mandos de la organizacin los cuales tienen la necesidad
de tener informacin exacta del estado de sus procesos de negocio.
22 Tecnologa Workow
2.5. Modelado de Workow
El modelado y especicacin de procesos de workow es un rea que ha sido investigada
por ms de una dcada. En la actualidad sigue siendo un rea de investigacin en el campo
acadmico, industrial y comercial. Se han reportado diversas propuestas para el modelado
de procesos de workow que poseen enfoques basados en extensiones de redes de Petri, en
lgebras de procesos o en lenguaje de modelado unicado (UML). A pesar de la gran cantidad
de propuestas de modelado, an no existe una metodologa grca estndar. A travs de
una extensin de las CCPN se propone una metodologa grca para modelar los conceptos
comunes que componen los procesos de workow de acuerdo a [21]. Con este trabajo de tesis
se pretende proporcionar una opcin para modelar grcamente, a travs de una herramienta
de software que sea fcil de comprender dirigida a usuarios que no tienen conocimientos sobre
redes de Petri. Adems, con este trabajo se extienden las aplicaciones en que tienen uso las
redes de Petri coloreadas condicionales. En esta seccin se presentan los aspectos relevantes
en cuanto al modelado de workow.
2.5.1. Perspectivas de modelado
Un proceso de workow puede ser modelado desde diferentes perspectivas. Cada perspec-
tiva representa de un proceso lo que considera ms importante o ms til para trabajar con
ste. De acuerdo a [15] la perspectiva de ujo de control (o de procesos) describe actividades
y su ejecucin, la perspectiva de datos delimita y describe el procesamiento de datos sobre la
perspectiva de control. La perspectiva de recursos provee la estructura organizacional (per-
sonas y dispositivos que tienen un rol responsable de ejecutar actividades). La perspectiva
organizacional describe las acciones elementales ejecutadas a travs de actividades donde las
acciones son mapeadas desde aplicaciones. A continuacin se describe con ms detalle cada
una de stas.
Flujo de control
Lo que concierne a esta perspectiva, es la ejecucin de las tareas dentro de un tiempo
especco(qu actividades han sido realizadas y en qu orden) [7]. En [23], se hace notar
que es esencial que un lenguaje provea de manera adecuada esta perspectiva para denir
workows, as como en la mayora de los trabajos realizados esta perspectiva es la que ms
importancia se le ha dado hasta el momento y es la que ms ha sido estudiada. La perspectiva
2.5 Modelado de Workow 23
de ujo de control podemos considerarla como la base de las siguientes perspectivas, ya que
las restantes descansan en sta.
Flujo de datos
Representa los datos que viajan a lo largo de las rutas del ujo de control, proceso
en el que los datos son consumidos y adems son creados nuevos datos, resultado de la
ejecucin del proceso. Bsicamente la unidad de datos ms importante referida en workow
es el documento, teniendo en cuenta que puede ste encontrarse en cualquier medio, ya sea
fsico (p. ej. un memorandum, un recibo de banco, etc.) o electrnico (p. ej. almacenamiento
en bases de datos, en formatos de procesadores de texto u hojas de clculo). Estos documentos
y las variables (datos de control) que deciden por dnde tienen que trazar su ruta dentro del
workow los propios documentos, son modelados dentro de esta perspectiva [23].
Recursos
En la perspectiva de recursos, las caractersticas relevantes acerca de los actores (usuarios
y empleados que laboran en la organizacin e inciden en el proceso que se est automatizan-
do) son modeladas. Es conocido que los actores son organizados en grupos de acuerdo a sus
funciones o roles dentro de la organizacin [7]. En esta perspectiva se modela la jerarqua or-
ganizacional y la forma en como interactan las personas que forman parte de la organizacin
y que forman parte del workow.
Otras perspectivas
Algunas otras perspectivas de modelado para un workow han sido investigadas y prop-
uestas en diferentes trabajos; algunas de stas son las siguientes:
Excepciones. Se encarga de modelar las posibles variaciones consideradas como situa-
ciones excepcionales de manera que puedan ser anticipadas y monitoreadas en la ejecucin de
un workow[24]. El modelado de excepciones se realiza en la mayora de los casos utilizando
el paradigma de reglas ECA. En [24] presentan una herramienta para la especicacin de
excepciones de workow modelados como disparos
4
(estos son acciones que se ejecutan de
manera automtica en una base de datos, en respuesta a modicaciones que se realicen sobre
4
Conocidos comnmente como triggers, que es su traduccin en ingls.
24 Tecnologa Workow
los datos que pertenecen a la base de datos). En ese trabajo se propone tener de manera pre-
denida un conjunto de estructuras de triggers genricos almacenados en una herramienta de
almacenamiento en forma de patrones. Al utilizar patrones pueden reutilizar determinados
conjuntos de triggers.
2.5.2. Tcnicas, lenguajes y herramientas de modelado de work-
ow
La modelacin de workow es tambin conocida como especicacin de workow. Para
modelar un workow es necesario un lenguaje o herramienta de modelado ya sea para mod-
elado en general o para modelar especcamente workows. De estos lenguajes o tcnicas
de modelado podemos obtener una clasicacin que nos permita observar sus ventajas y
desventajas. En primer lugar pueden ser clasicadas en dos grupos: Formales y No formales.
A partir de dicha clasicacin podemos hacer una distincin entre las tcnicas que ofrecen
un ambiente grco para el modelado y las que no lo ofrecen.
La formalidad es un principio que tradicionalmente no es bien acogido en el campo de
los sistemas de informacin. Muchos lenguajes han sido propuestos sin tener fundamentos
formales. Con el tiempo ha venido a ser claro que est no es una situacin del todo deseable.
Las tcnicas de modelado formales, descansan sobre bases matemticas que permiten que el
modelo obtenido sea validado tanto sintcticamente como semnticamente, esta es la principal
ventaja ya que permite que un modelo sea analizado y vericado, asegurando as en mayor
grado la ausencia de errores. Su principal desventaja, es que son tcnicas que pueden requerir
un poco de ms conocimiento o aprendizaje por parte de la persona que modela los procesos.
Ejemplos de este tipo de tcnicas son:
Redes de Petri
Mquinas de estados
Lgica temporal
Con las tcnicas informales se tiene prcticamente lo contrario, es decir, el uso de s-
tas suele resultar de mayor facilidad y ms comprensin al no estar atadas a restricciones
matemticas. Sin embargo, la principal desventaja es el no poder vericar los modelos
obtenidos, con lo que es necesario esperar hasta tener el sistema desarrollado e implementado
para vericar que todos sus mdulos funcionan como se modelaron a travs de alguna de
las tcnicas informales. Lo anterior por supuesto, no es recomendable ya que incrementa los
costos de desarrollo.
Ejemplos:
UML
Diagramas de ujo
Diagramas IDEF
Los lenguajes sin una semntica formal fcilmente son susceptibles a ser inherentemente
ambiguos. Una solucin que en ocasiones es adoptada, es la de modelar los procesos uti-
lizando una tcnica informal para despus mediante algn algoritmo de conversin generar la
representacin en alguna tcnica formal, para de esa manera validar el modelo. Sin embargo,
adems de tener como resultado un trabajo extra, es muy difcil que el modelo obtenido
represente de manera correcta el modelo original.
En [25] se muestra cmo la nueva versin de UML, la 2.0 (anteriormente 1.5) sigue care-
ciendo de una semntica formal, y se muestra el trabajo de como con CPN son mapeados
los modelos hechos con Diagramas de Actividad a estructuras de CPN para poder vericar
semnticamente el modelo.
Estndares para modelado
Los siguientes estndares utilizados para modelar procesos de workow son los siguientes:
XPDL, UML, BPEL, WSFL, BPML.
XPDL (XML Processing Description Language). Es la forma estndar para intercambiar
deniciones de workows entre diferentes productos de software sin importar la plataforma o
la metodologa grca utilizada para denir los procesos, ya que stos son mapeados a XPDL
que est basado en XML como una representacin intermedia que utilizan los diferentes pro-
ductos de software WfMS (Workow Managament Systems). Este estndar slo se encuentra
como gramtica, no como estndar grco.
UML (Unied Modelling Language) es el lenguaje de modelado de sistemas de software
ms conocido en la actualidad, apoyado por la OMG (Object Management Group). UML
cuenta con varios tipos de modelos, los cuales muestran diferentes aspectos del sistema mod-
elado, particularmente para modelar workows son utilizados los diagramas de actividad y
en menor medida, los diagramas de secuencia.
26 Tecnologa Workow
BPEL (Business Process Execution Language) es un lenguaje comn normalizado que
tiene como objetivo principal optimizar la coordinacin de procesos de negocios y servicios
web; proporciona una especicacin formal de los procesos y sus interacciones. Existe una
extensin para modelar servicios web BPEL4WS.
WSFL (por sus siglas en ingls, Web Services Flow Language) es un lenguaje basado en
XML propuesto por IBM para describir composicin de servicios Web, sin embargo ha sido
reemplazado por BPEL y BPEL4WS.
BPML (por sus siglas en ingls, Business Process Modeling Language) es un meta lengua-
je para el modelado de procesos de negocio; as como XML, slo es un meta lenguaje para
el modelado de datos de negocio. BPML provee una ejecucin abstracta del modelo para
procesos colaborativos y transaccionales basados en el concepto de mquina transaccional de
estados nitos.
Software existente
Las compaas de software y desarrollos acadmicos que se enfocan en la produccin e
investigacin de sistemas administradores de Workow las encontramos en gran cantidad. A
continuacin mencionamos los que de acuerdo a nuestra investigacin resultan ser los ms
completos y/o conocidos.
En [15] se realiz un estado del arte sobre la industria, en donde se tiene un anlisis
no rigorista de 8 sistemas de software importantes, en donde es posible apreciar las diversas
formas y las similitudes encontradas para modelar los diferentes conceptos de workow. Estos
productos son: FileNets Visual WorkFlow, Fort Conductor, Changengine, Staware, Fujitsu
i-Flow, MQSeries Workow, Verve, SAP R3 Workow. Otros sistemas conocidos y que son
referenciados en [16] son InConcert, Eastman, FLOWer, Domino, Meteor, Mobile y COSA
este ltimo basado en redes de Petri.
2.5.3. Redes de Petri para modelar Workows
En base a diversos trabajos de investigacin realizados desde inicios de los aos 90s
que han utilizado diversas modicaciones de redes de Petri para el modelado de Workows a
continuacin mostramos una lista de ventajas que han sido identicadas desde siempre debido
a las propiedades inherentes del modelo de red de Petri y su relacin con los workows. As
mismo, mostramos algunos argumentos encontrados en la literatura que sugieren que las
redes de Petri no son del todo buenas para modelar procesos Workow.
Ventajas y razones del modelado de procesos workow con redes de Petri
Semntica Formal. Las bases matemticas en las que descansa la teora de redes de
Petri proveen deniciones precisas y una semntica clara.
Naturaleza grca. La representacin grca de las redes de Petri es bastante sencilla
e intuitiva, fcil de aprender, y existen muchas aplicaciones de software que permiten de
manera sencilla y genrica disear y modelar sistemas.
Expresividad. Las redes de Petri bsicas pueden soportar primitivas funcionales nece-
sarias para modelar sistemas de workow de documentos sin tener detalle de qu contienen
dichos documentos. Sin embargo podemos agregar expresividad con las extensiones de datos
y de tiempo a nuestros modelos, por medio de las diferentes extensiones a las redes de Petri.
Anlisis. Un conjunto completo de tcnicas de anlisis han sido desarrollados para ver-
icar propiedades de un sistema modelado con redes de Petri: (safety, invariance, deadlock,
etc.) y para calcular medidas de rendimiento en el modelo (response times, waiting times,
occupation rates, etc.).
Puntos en contra
Algunos autores como en [7] exponen las carencias y las desventajas de modelar con redes
de Petri los procesos de workow. Particularmente en ese trabajo son utilizados los diagramas
de actividad de UML proveyndoles de una semntica formal (ya que originalmente no la
poseen, tampoco en su nueva versin UML 2.0). En [7] tambin se presenta uno de los
argumentos ms simples que pueden ser encontrados. Se menciona que las redes de Petri
fueron inventadas antes de que lo fuesen los sistemas de administradores de Workow. Por lo
tanto no poseen las caractersticas necesarias. Sin embargo pensamos que por esa misma razn
han surgido diversas modicaciones o extensiones para modelar workows de una manera ms
natural. Otro argumento es que las redes de Petri slo sirven para modelar sistemas cerrados
y no sistemas reactivos, ya que en [7] se considera un workow como un sistema reactivo, esto
es por la naturaleza de disparo de las transiciones de las redes de Petri. En [9] se argumenta el
28 Tecnologa Workow
porqu las redes de Petri de alto nivel no proporcionan los elementos sucientes para modelar
ciertas situaciones que pueden aparecer en un proceso de workow.
2.6. Comentarios nales
En este captulo se presentaron las caractersticas que posee un sistema de workow, as
como las ventajas de implementar un sistema administrador de workows en una empresa.
Se describi lo que representa y constituye un proceso de negocio o proceso de workow. Los
elementos que conforman un proceso de este tipo pueden ser modelados y representados por
varias herramientas. El modelado de workow es una de las grandes reas de investigacin
respecto al tema workow. En el siguiente captulo se expone la teora de redes de Petri que
es utilizada para denir la propuesta de modelado para procesos de workow que se presenta
en este trabajo de tesis.
Captulo 3
Redes de Petri
Este captulo est dedicado a la teora de redes de Petri con el n de comprender de
mejor manera las Redes de Petri Coloreadas Condicionales (Conditional Colored Petri Net,
CCPN)
1
. Adems aqu se revisan los conceptos bsicos de redes de Petri coloreadas.
3.1. Introduccin a las Redes de Petri
Las redes de Petri se deben a la tesis doctoral Kommunikation mit Automaten
2
del
alemn Carl Adam Petri presentada en la facultad de matemticas y fsica de la Universidad
Tcnica de Darmstadt en 1962.
Una Red de Petri (Petri Net, PN
3
por sus siglas en ingls) es una herramienta grca y
matemtica que ayuda a describir relaciones entre condiciones y eventos presentes en los sis-
temas del mundo real. Las caractersticas de un sistema que son modeladas utilizando PN son
algunas de las siguientes: sincronizacin de procesos, eventos asncronos, operaciones secuen-
ciales, operaciones concurrentes, conictos con recursos compartidos, procesos distribuidos,
procesos paralelos, procesos no determinsticos y/o estocsticos.
Un sistema modelado a travs de PN puede ser analizado de manera formal, obteniendo
informacin de su comportamiento dinmico. Adems es posible vericar propiedades que
1
A lo largo de este trabajo nos referiremos a las redes de Petri coloreadas condicionales por sus siglas en
ingls: CCPN.
2
La traduccin al ingls: Communication with Automata. New York: Griss Air Force Base. Tech. Rep.
RADCTR-65-377, vol.1, Suppl. 1, 1966
3
En esta tesis, una red de Petri es referida por sus siglas en ingls PN.
30 Redes de Petri
debe mantener el sistema. Por ejemplo, se puede vericar que no se encuentren estados
inalcanzables en el sistema o vericar que no existan candados mortales (deadlocks) dentro
del modelo.
Dos conceptos importantes en el modelado de sistemas dinmicos son los eventos y las
condiciones. Los eventos son acciones que se presentan en el sistema y lo llevan a un estado.
Es posible describir un estado como un conjunto de condiciones; para que cierto evento ocurra
es necesario que ciertas condiciones se cumplan; a stas se les llama precondiciones del evento,
as mismo, la ocurrencia del evento puede llevar a otras condiciones; stas se conocen como
postcondiciones.
Al modelar con PN es necesario identicar las condiciones (pre y poscondiciones), as
como los eventos que pueden suceder en l. De esta manera se traslada el sistema de la vida
real al modelo en PN. La tarea de modelado es una actividad subjetiva. Es decir, el modelado
de un sistema puede realizarse de diferentes maneras. As cuando diferentes personas realizan
el modelo de un mismo sistema, los modelo resultantes pueden diferir considerablemente; sin
embargo ambos estarn modelando el comportamiento del sistema. Al tener las condiciones
necesarias para que ciertos eventos del sistema sucedan, es posible modelar de forma modular,
y de esta manera relacionar los modelos con otras condiciones; para esto es necesario conocer
la estructura de la PN.
En [26] se presenta la tabla de la gura 3.1, en la que se muestra cmo una condicin puede
ser modelada a travs de un lugar y un evento a travs de una transicin. De esta manera
una precondicin puede ser modelada empleando un lugar de entrada y una postcondicin
con un lugar de salida. En la tabla se muestran algunas maneras de interpretar los lugares y
las transiciones.
Las redes de Petri poseen una parte matemtica y una grca. Por lo tanto, pueden ser
estudiadas formalmente a travs de su estructura matemtica y en su forma grca a travs
de su representacin visual en forma de grafo dirigido.
3.1.1. Elementos
Una red de Petri es un grafo bipartito dirigido y se compone de los siguientes elementos:
Un conjunto de lugares (nodos).
3.1 Introduccin a las Redes de Petri 31
Bfer Procesador Bfer
Conclusiones Clusula en lgica Condiciones
Liberacin de recurso Tarea Requerimiento de
recurso
Seales de salida Procesamiento de
seales
Seales de entrada
Datos de salida Procesamiento Datos de entrada
Postcondiciones Evento Precondiciones
Lugares de salida Transiciones Lugares de entrada
Bfer Procesador Bfer
Conclusiones Clusula en lgica Condiciones
Liberacin de recurso Tarea Requerimiento de
recurso
Seales de salida Procesamiento de
seales
Seales de entrada
Datos de salida Procesamiento Datos de entrada
Postcondiciones Evento Precondiciones
Lugares de salida Transiciones Lugares de entrada
Figura 3.1: Posibles interpretaciones para los lugares y las transiciones en una red de Petri
Un conjunto de transiciones.
Una funcin de entrada
Una funcin de salida.
Marcado Inicial
Las funciones de entrada y de salida relacionan a los lugares con las transiciones y vicev-
ersa. La funcin de entrada es un mapeo de una transicin t
j
a un conjunto de lugares
conocidos como los nodos de entrada de una transicin. La estructura de una PN es denida
por los nodos, las transiciones, la funcin de entrada y la funcin de salida. A continuacin
se presenta la denicin formal de una PN.
3.1.2. Denicin formal
La estructura de una red de Petri es PN = (P, T, F, W, M
0
) donde:
P = {p
1
, p
2
, ..., p
m
} es un conjunto nito de lugares (nodos), donde m 0.
T = {t
1
, t
2
, ..., t
n
} es un conjunto nito de transiciones, donde n 0.
F (P T) (T P) es un conjunto de arcos
W : F {1, 2, 3, ...} es una funcin de peso
M
0
: P {0, 1, 2, 3, ...} es la marca inicial
32 Redes de Petri
Lugares.
Transiciones.
Arcos de entrada.
Arcos de salida.
Tokens.
P
T
I(f,t)
O(t,f)
M()
Figura 3.2: Representacin grca de los elementos de una red de Petri.
Para denir el concepto de marca inicial es necesario referirse a los tokens. Un token es un
concepto primitivo que forma parte de las PN, el cual es asignado a cada uno de los lugares,
a esta asignacin se le conoce como marca, un lugar puede contener n tokens. Los tokens
deciden la ejecucin en la red de Petri. Por lo tanto la cantidad y la posicin de los tokens
cambia durante la ejecucin. El paso de los tokens a travs de las transiciones y los lugares
de la PN, es utilizado comnmente para interpretar la ejecucin del sistema modelado.
Como herramienta matemtica es posible obtener ecuaciones de estado, ecuaciones al-
gebraicas y otros modelos matemticos que describen el comportamiento de los sistemas.
Mientras que como herramienta grca sta permite obtener un concepto visual del sistema,
a continuacin se describe la representacin grca.
3.1.3. Representacin grca
La representacin grca de una PN es importante ya que si se observa el modelo del
sistema en forma grca y la manera en que cambia de un estado a otro, es posible mantener
la atencin y obtener una perspectiva ms clara del anlisis del problema. En la gura 3.2 se
muestra la representacin grca de los elementos que forman una red de Petri.
Los lugares son representados con crculos, las transiciones se representan mediante una
barra o un rectngulo, los arcos dirigidos que conectan a los lugares con las transiciones y
viceversa son representados con echas. Los tokens son representados con pequeos crculos
de color negro que van dentro de los lugares.
Un arco dirigido desde un lugar p
j
(transicin t
i
) a una transicin t
i
(lugar p
j
) dene a
p
j
como un lugar de entrada (salida) de t
i
, el cual describe como w(p
j
, t
i
) = w(t
i
, p
j
) = 1. Si
w(p
j
, t
i
) = k( o w(t
i
, p
j
) = k), entonces existen k arcos dirigidos (paralelos) que conectan el
lugar p
j
con la transicin t
i
(o que conectan la transicin t
i
con el lugar p
j
). Generalmente
en un esquema grco, los arcos paralelos que conectan a un lugar (transicin) con una
transicin (lugar) se representan por un solo arco dirigido, etiquetado con el nmero de arcos
que representa a su peso k. Un lugar que contiene un punto en su interior representa a un
lugar que contiene un token. La capacidad de almacenamiento de tokens en cada lugar es
innita, y para denotar el numero de tokens o marcado de un lugar se utiliza M(p).
3.1.4. Regla de disparo
La ejecucin de una PN es controlada por el nmero y distribucin de los tokens. La
ejecucin de la red de Petri se activa disparando sus transiciones. Cuando una transicin es
disparada se remueven tokens de los lugares de entrada y se crean tokens en los lugares de
salida. El nmero de tokens que son removidos es igual al peso del arco que conecta al lugar
de entrada con la transicin que fue disparada. De igual manera el nmero de tokens creados
est dado por el peso del arco que conecta la transicin con el lugar de salida.
Para que una transicin pueda dispararse, requiere estar habilitada, Dicha habilitacin
depende de una condicin conocida como regla de habilitacin. Esta regla se describe a
continuacin:
Una transicin t se dice que ser habilitada si cada lugar de entrada p de t contiene al
menos un nmero de tokens igual al peso k del arco dirigido que conecta a p con t, es decir,
que M(p) w(p, t) para algn p en P. En la gura 3.3 se muestra la regla de disparo y
algunos ejemplos.
La gura 3.3 a) muestra la condicin de habilitacin. Cuando se omite el peso del arco
por convencin el peso es 1, no sucede as con el nmero de tokens. Es decir, si no existen
tokens el nmero de tokens es 0. Es as como en el ejemplo mostrado en la gura 3.3 b) la
red no se habilitar nunca ya que el peso del arco es 1 y no es ni mayor ni igual a 0, que es
el nmero de tokens en el lugar. Un caso similar se da en el ejemplo de la gura 3.3 c). Sin
embargo, la gura 3.3 d) muestra un ejemplo en el que la transicin s se activar ya que el
nmero de tokens en el lugar es mayor al peso de su transicin.
Una transicin activada puede o no dispararse, (dependiendo de la interpretacin adicional
que tenga la transicin). Esencialmente el disparo de las transiciones y el cambio de tokens
34 Redes de Petri
M(p) I(t,p), donde t T, p P
n
m
p
t
La transicin se activa si n m
p
t
6
p
t
Nunca se habilitar
No se activa ya que existen 4 tokens, que son
menos al peso del arco
3
p
t
Se activa ya que existen 4 tokens, que son mayor
al peso del arco
a)
b)
c)
d)
Figura 3.3: Habilitacin de transiciones en una red de Petri
entre los lugares de la red, es lo que permite ver el comportamiento dinmico de un sistema.
A lo anterior se le conoce como la ejecucin del juego de tokens de la PN.
En la gura 3.4 se muestra la ejecucin de una PN sencilla. En ella podemos vericar
cmo el peso de los arcos decide el nmero de tokens que son removidos del lugar de entrada
y el nmero de tokens creados en el lugar de salida. Tambin podemos observar que llega un
momento en que el lugar de salida queda sin tokens, esto es despus del tercer disparo. Esto
provoca la deshabilitacin de la transicin y la ausencia de posteriores disparos en el sistema,
hecho que podramos interpretar como la nalizacin de nuestro sistema, o el agotamiento de
sus recursos, esto es dependiendo de la interpretacin con que modelamos nuestro sistema.
3.1.5. Ejemplo
A continuacin se presenta un ejemplo clsico [26] el cual a pesar de su sencillez ilustra
claramente la idea de cmo utilizar las redes de Petri.
El ejemplo de la gura 3.5 muestra la bien conocida reaccin qumica: 2H
2
+O
2
2H
2
O.
El marcado inicial de la red de Petri est dado por dos tokens en el lugar de entrada H
2
(se
representan dos molculas de H
2
) y dos tokens en el lugar de entrada O
2
(se representan dos
2
p
1
t
p
2
2
p
1
t
p
2
2
p
1
t
p
2
Disparo 1
Disparo 2
2
2
2
Disparo 3
:
Disparo n
Figura 3.4: Ejemplo de una secuencia de disparos en una red de Petri.
O
2
H
2
H
2
O
2
2
O
2
H
2
H
2
O
2
2
t
t
a)
b)
Figura 3.5: Ejemplo de una red de Petri.
36 Redes de Petri
molculas de O
2
). La transicin se encuentra activada ya que en el primer caso el peso del
arco es 2 y el nmero de tokens cumple la regla de activacin PesoArco <= NumTokens al
tener ms de un lugar de entrada la transicin t requiere que en todos los arcos se cumpla la
regla de activacin. El peso del arco del lugar O
2
tambin cumple al tener un valor menor al
nmero de tokens del lugar con que conecta. Despus del disparo de la transicin t, la red de
Petri toma el estado presentado en la gura 3.5 b). Claramente se observa que la transicin
t nunca volver a estar activa. El resultado son dos molculas de H
2
O.
3.1.6. Propiedades y mtodos de anlisis
Una de las mayores ventajas de utilizar tcnicas de modelado que poseen semntica for-
mal (tal es el caso de las redes de Petri) es que el modelo obtenido, puede ser analizado a
travs de tcnicas matemticas. Las PN poseen propiedades que permiten analizar la correc-
titud del modelo desde distintas perspectivas, principalmente en aspectos de concurrencia y
paralelismo.
Dos tipos de propiedades pueden ser estudiadas en un modelo de red de Petri[26]:
Las que dependen del marcado inicial (comnmente referidas como propiedades de
comportamiento).
Las que son independientes del marcado inicial (propiedades estructurales).
A continuacin se describe brevemente cada una de las propiedades de comportamiento
ya que estas propiedades son de ms inters en la tarea de modelar los procesos de tipo
workow que fueron presentados en el captulo anterior. Esto es debido al inters de conocer
el comportamiento y las propiedades estructurales en un proceso de negocios. En [26] es
posible profundizar en el tema de las propiedades de una PN.
Propiedades de comportamiento
Alcanzabilidad. Una secuencia de disparos da lugar a una secuencia de marcados. Un
marcado M
n
se dice que es alcanzable desde un marcado M
0
si existe una secuencia de
disparos que transforma M
0
en una red (N, M
n
); se denota por R(N, M
0
). Un disparo o
secuencia de ocurrencias es denotado por = M
0
t
1
M
1
t
2
M
2
...tn Mn o simplemente
= t
1
t
2
...t
3
. En este caso, M
n
es alcanzable desde M
0
a travs de por lo que se escribe
M
0
[ > M
n
]. El conjunto de todos los posibles marcados que hacen alcanzable a M
0
en una
red (N, M
0
) es denotado por L(N, M
0
) o simplemente por L(M
0
). Con lo anterior podemos
denir el problema de la alcanzabilidad: Encontrar si M
n
R(M0) para un marcado M
n
dado en una red (N, M
0
).
Acotamiento. Una red (N, M
0
) se dice que est k-acotada o simplemente acotada si el
nmero de tokens en cada lugar no excede un nmero nito k para ningn marcado alcanzable
desde M
0
. Una red de Petri se dice que es segura si es 1-acotada [20]. El trmino segura se
reere al conocimiento del nmero de tokens k que habr siempre en los lugares de la red.
Lo anterior, cierto tipo de sistemas lo requieren con el n de que los elementos representados
por los tokens no tiendan a innito, con lo cual aseguran estabilidad en el sistema.
Vivacidad. Este concepto est relacionado con la ausencia total de candados mortales
o deadlocks como son conocidos en el rea de sistemas operativos. El concepto: viva, est
estrechamente relacionado con la situacin de candado mortal (deadlock), el cual ha sido
situado en el mbito de los sistemas operativos. Una red de Petri que modela un sistema y se
encuentra libre de candados mortales es viva. Esto implica que para alguna marca alcanzable
M, es posible disparar al menos una transicin en la red a travs de alguna secuencia de
disparo. Sin embargo, este requisito debe ser bastante estricto para representar algn sistema
real o escenarios donde se presente un comportamiento libre de candados mortales [20].
Persistencia. Una red de Petri se dice que es persistente si en el caso de tener dos
transiciones cualesquiera habilitadas, el disparo de una no deshabilita a la otra transicin.
La nocin de persistencia es utilizada en el contexto de programas paralelos [26].
3.1.7. Extensiones de las redes de Petri bsicas
Las extensiones o modicaciones a las redes de Petri bsicas fueron desarrolladas de
acuerdo a necesidades que han surgido en el rea de investigacin referida a modelado de
sistemas. Existen algunas extensiones de redes de Petri que presentan ciertas variaciones
contra la estructura original. Estas variaciones fueron desarrolladas con la nalidad de cubrir
caractersticas de sistemas que no manejan nicamente eventos y condiciones debido a que
existen sistemas que necesitan incluir informacin en forma de datos o variables. En ciertos
casos es necesario manejar intervalos de tiempo u otras propiedades con el n de representar
las caractersticas del sistema modelado.
38 Redes de Petri
Algunas extensiones de redes de Petri son las siguientes:
Red de Petri Coloreada
Red de Petri Difusa
Red de Petri Estocstica
Red de Petri con Tiempo
Red de Petri Temporizada
En la siguiente seccin se presenta una de estas extensiones: la red de Petri coloreada (Col-
ored Petri Net, CPN por sus siglas en ingls) de la cual se presenta una breve descripcin.
Posteriormente se presentan brevemente las redes de Petri coloreadas condicionales (Condi-
tional Colored Petri Net, CCPN por sus siglas en ingls) que fueron propuestas en [20], [19]
para modelar bases de datos activas. En este trabajo de tesis se extienden sus caractersticas
para modelar procesos de workow.
3.2. Red de Petri Coloreada
Las Redes de Petri Coloreadas (CPN por sus siglas en ingls), fueron desarrolladas por el
grupo de la Universidad de Aarhus [18] dirigidos por Kurt Jensen hace ya ms de 20 aos.
El desarrollo de las redes de Petri coloreadas (CP-nets o CPN) fue dirigido por el deseo
de desarrollar un lenguaje de modelado, que fuese tericamente bien formado y lo sucien-
temente verstil para ser usado en sistemas prcticos, del tamao y complejidad tpicos en
proyectos de la industria [27].
Una CPN combina el poder de modelado de una PN bsica con la expresividad de un
lenguaje de programacin de alto nivel, sto se logra al permitir la representacin de diferentes
tipos de datos en el modelo, utilizando para ese n los tokens que circulan a travs de la red. A
diferencia de una PN en la que todos los tokens son de color negro, en una CPN se introduce
el concepto de color del token o token coloreado, teniendo as tokens de diferentes colores, por
lo tanto se tiene que un color = dato. Las caractersticas particulares de las CPN proveen
un mayor potencial para el modelado de sistemas. Las expresiones de arco y las guardas de
3.2 Red de Petri Coloreada 39
las transiciones permiten restringir mejor las condiciones de disparo de las transiciones en
una CPN con respecto a las PN clsicas. El empleo de colores y de expresiones de arco hace
que el modelo que se obtenga con CPN sea ms compacto que el modelo equivalente con PN
clsicas.
Cada token puede transportar informacin cuyo tipo depende del lugar donde est colo-
cado, por tal razn en las CPN se incluye el concepto de dominio de color para cada lugar.
Este dominio constituye el tipo de dato asociado a los tokens que pueden llegar a cada lugar.
Los cambios de estados en una CPN son llevados a cabo mediante la activacin y disparo
de las transiciones como en una PN bsica. Sin embargo como ahora se tiene diferenciacin
entre los tokens de un lugar, es necesaria informacin adicional que permita conocer qu
tipo de tokens deben de ser removidos de un lugar de salida y qu tipo de tokens deben ser
generados en un lugar de entrada teniendo en cuenta los colores de stos. A continuacin se
describe la denicin formal de una CPN y los conceptos que permiten modelar utilizando
esta extensin de PN.
La estructura de una red de Petri coloreada es CPN = {P, T, C
, C
+
, cd} donde:
P es el conjunto nito de lugares.
T es el conjunto nito de transiciones.
C es el conjunto nito de clases de colores para los tokens.
cd : P T C es una funcin que dene el dominio de color de cada lugar a transicin.
C
[p, t], C
+
[t, p] : cd(t) Bag(cd(p)) son las matrices de transicin previa y posterior
respectivamente.
Los estados en una red de Petri coloreada son representados por los lugares p P.
Grcamente stos son representados por crculos y el nombre de cada lugar se escribe dentro
de stos. Cada lugar tiene asociado un tipo (color) el cual determina el tipo de dato que el
lugar puede contener. Por convencin, el nombre del tipo es escrito cerca del crculo con letras
itlicas [28]. De esta manera, cuando se ejecute la CPN los tokens que lleguen a un lugar
debern ser del mismo tipo que tiene asociado el lugar, recordando que los tokens representan
un tipo de dato segn su color.
40 Redes de Petri
3.2.2. Marcado y regla de disparo
Formalmente el marcado de una CPN es un vector indexado con respecto a los lugares,
el cual asigna a cada uno de los lugares p un multiconjunto denido sobre cd(p) : M[p]
Bag(cd(p)).
Se denota como M[p, c] al nmero de tokens c cd(p) que estn presentes en M[p]. En las
PN se tiene un marcado inicial, el cual es denotado como M
0
. El marcado inicial en una CPN
es denido utilizando una notacin formal basada en sumas y se especica de la siguiente
manera:
M
0
= p
5
(b
1
+... +b
nb
) +p
6
(e
1
+... +e
nc
) +p
7
(m
1
+... +m
nc
), .
Para que una transicin t en una CPN est habilitada, debe disponer de un nmero
suciente de tokens en sus lugares de entrada (condicin bsica de una PN). Adems, los
valores de esos tokens deben corresponder a las expresiones de los arcos de entrada. Una
transicin t opcionalmente puede tener una condicin de guarda. De esta manera si est
habilitada slo se disparar si satisface su condicin de guarda. En las expresiones de arco y
en las condiciones de guarda se pueden utilizar variables, que corresponden a alguno de los
tipos vlidos, o bien constantes (colores).
El disparo de una transicin coloca en los lugares de salida los valores correspondientes,
en cuanto a color y multiplicidad, segn la evaluacin que se haga de las expresiones de los
arcos de salida. Con esta funcionalidad es posible representar datos en el modelo del sistema
que se representa con CPNs.
3.2.3. Ejemplo
En la gura 3.6 se muestra un breve ejemplo que ilustra la forma de uso de una red de
Petri coloreada.
En el ejemplo se muestra que cada uno de los lugares tiene un tipo de dato asociado,
este puede ser bsico (Integer o String o Float, etc.) o tambin puede tratarse de una
composicin de tipos como por ejemplo: Integer Data el cual es un producto de tipos. El
conjunto de colores o datos se muestra en la gura 3.7.
3.2 Red de Petri Coloreada 41
p
1
[s=p]
p
2
t
1
t
2
p
3
DATA
INTxDATA
INT
1( cadena A)
1( 3,cadena B)+5(6,cadena A)
(n,s)
3p
p
3p
3n p
1
[s=p]
p
2
t
1
t
2
p
3
DATA
INTxDATA
3(6)
1( 3,cadena B)+4(6,cadena A)
(n,s)
3p
p
3p
3n
INT
Figura 3.6: Ejemplo de una red de Petri coloreada
Type INT = Integer
Type DATA = String
Type INTxDATA = producto INT*DATA
Var n : INT
Var p, s : DATA
Figura 3.7: Denicin de tipos (colores) para el ejemplo de la gura 3.6.
42 Redes de Petri
Cada color posee su multiplicidad, con lo que se indica cuantas copias del dato se encuen-
tran en el lugar. En la CPN de la gura 3.6 el lugar p
1
posee 6 tokens, uno de estos tokens
es un INT DATA con valor de (3, cadenaBj), mientras que los otros 5 tokens poseen el
valor (6, cadenaAj).
Los arcos de entrada y de salida de las transiciones, poseen variables para restingir el
paso de datos, es decir nicamente los datos que se especiquen en el arco podrn transitar
a travs de l, debido a que la transicin slo ser habilitada cuando datos de ese tipo se
encuentren en el lugar de entrada.
En la CPN de la gura 3.6 la transicin t
1
ser habilitada ya que existen ms de un tipo
de dato (INT DATA) en el lugar p
1
y en el lugar p
2
existe por lo menos un token de tipo
DATA, es el tipo que se pide transite por el arco que conecta a p
1
con t
1
por lo tanto al
cumplirse las dos condiciones en los arcos de entrada que conectan a la transicin t
1
sta
se dispara. Con la transicin t
2
se tiene el caso en que no ser habilitada y por lo tanto no
ser disparada, esto es debido a que el peso del arco que conecta a p
2
con t
2
especica que
deben ser 3 tokens de tipo p, siendo que en el lugar p
2
nicamente se tiene un token el cual
es 1
0
(cadenaAj) con lo que no se cumple ni siquiera la condicin bsica de una PN que
establece que el nmero de tokens en el lugar de entrada debe ser mayor o igual al peso del
arco que lo conecta con la transicin en cuestin. Por ltimo tenemos que en el lugar p
3
se
crean 3 tokens de tipo n, es decir nicamente el tipo INT se mantiene, desechndose el tipo
DATA en este caso la marca resultante es 3
0
(6).
A continuacin se presenta brevemente lo que son las redes de Petri coloreadas condi-
cionales, las cuales son una modicacin de las redes de Petri coloreadas presentadas en esta
seccin.
3.3. Red de Petri Coloreada Condicional
Las redes de Petri coloreadas condicionales (Conditional Colored Petri Net, CCPN por sus
siglas en ingls) fueron concebidas como una modicacin a las CPN para modelar, analizar
y ejecutar reglas ECA (Evento Condicin Accin), aplicadas al estudio de bases de datos
activas. En [20] se encuentran algunos resultados del trabajo realizado sobre modelado de
bases de datos activas utilizando CCPN.
3.3 Red de Petri Coloreada Condicional 43
Como propsito y justicacin de las CCPN es posible mencionar lo siguiente: La tran-
sicin de una red de Petri no tiene la capacidad de realizar la evaluacin de expresiones
lgicas, solamente evala la presencia o ausencia de tokens en sus lugares de entrada. Pero,
si agregamos a la transicin la capacidad de evaluar expresiones lgicas entonces la parte
condicional de la regla puede representarse como una transicin de red de Petri [20].
La CCPN es una extensin de PN, la cual hereda algunos de sus atributos, como la regla
de disparo de transiciones. Adems, en la CCPN se toman conceptos que estn presentes en
la denicin de la red de Petri coloreada (CPN), tales como la denicin de tipos de datos,
asignacin de colores (valores) a los tokens, y la asignacin de tipos de datos a los lugares.
En CPNs la asignacin de tipos de dato se hace hacia todos los lugares de la CPN, en el
caso de la CCPN, la asignacin de tipos de datos a lugares no es general, ya que en la CCPN
se manejan lugares (lugares virtuales) los cuales poseen la capacidad de alojar tokens de
diferentes tipos de datos.
En cuanto a la representacin de reglas ECA con CCPN se considera lo siguiente: en una
regla ECA se evala la condicin de la regla. En la CCPN se utiliza una funcin que realiza
la evaluacin de la parte condicional de la regla ECA almacenada en una transicin, mientras
que a travs de lugares de entrada de la transicin se representan los eventos, en contraste,
con los lugares de salida se representan las acciones. En [20], [19] se encuentra la denicin
de una CCPN para modelar conjuntos de reglas ECA presentes en bases de datos activas. A
continuacin se describen los elementos de una regla ECA.
3.3.1. Denicin de Reglas ECA
Para comprender de manera ms amplia lo que es una regla ECA y para lo que es
utilizada, a continuacin se presenta de forma breve su modelo de conocimiento. El modelo de
conocimiento describe las caractersticas estructurales de las reglas ECA de forma individual.
Cada elemento que conforma una regla ECA se describe a continuacin:
Evento.
Un evento es algo que sucede en un instante de tiempo dado. Se utiliza un mecanismo de
programacin para permitir que un programa de aplicacin seale la ocurrencia de un evento,
por ejemplo, como respuesta a alguna informacin introducida por el usuario. Adems de los
44 Redes de Petri
eventos comunes generados ya sea por el sistema de acuerdo a su ujo de ejecucin o a tareas
iniciadas por un usuario del sistema, se consideran las siguientes:
Excepcin. El evento sucede como resultado de una excepcin, por ejemplo, intentar
acceder a un documento que no existe.
Reloj. El evento sucede en un instante de tiempo que puede ser absoluto, relativo a
otro acontecimiento o peridico.
Externo. El evento que sucede por una situacin fuera del sistema, por ejemplo, una
consulta de informacin de un sistema perteneciente a otra empresa.
Un evento puede ser de dos tipos: primitivo o compuesto [20]. El evento es primitivo
cuando sucede por una ocurrencia de cualquiera de las fuentes descritas anteriormente.
Un evento es compuesto cuando sucede por una combinacin de eventos primitivos o com-
puestos usando un rango de operadores que constituyen el lgebra de eventos. Los operadores
de eventos ms comunes son los siguientes:
1. Disyuncin, < E
1
o E
2
> sucede cuando cualquiera de los eventos E
1
o E
2
ocurre.
2. Conjuncin, < E
1
y E
2
> sucede cuando ambos eventos E
1
y E
2
ocurren en cualquier
orden.
3. Secuencia, < sec(E1, E2) > sucede cuando E
1
ocurre antes que E
2
.
4. Cerradura, < cerradura(E) en Int > sucede la primera vez que E ocurre en el intervalo
de tiempo Int, sin importar las posteriores ocurrencias de E;
5. Historia, < veces(n, E) en Int > se seala cuando el evento E ocurre n veces durante
el intervalo de tiempo Int.
6. Negacin, < negaci on(E) en Int > detecta la no ocurrencia del evento E en el intervalo
de tiempo Int.
7. ltimo, < last(E) en Int >, toma la ltima ocurrencia del evento E en el intervalo de
tiempo Int.
3.3 Red de Petri Coloreada Condicional 45
8. Simultneo, < sim(e1, e2) > ocurre cuando suceden al mismo tiempo los eventos E
1
y
E
2
; alguno, < any(E
1
, E
2
, ..., E
n
, E
m
) > ocurre cuando han sucedido m eventos de n
posibles.
Estos eventos son los ms comunes que se reeren en la literatura sobre algebras de eventos
presentados en [20].
Condicin.
La condicin de una regla evala el contexto en el cual el evento tom lugar. En las reglas
ECA la condicin puede ser opcional. Si la condicin no se especica, entonces se obtienen
reglas de la forma evento - accin. Sin embargo, si el evento y la condicin son opcionales,
uno de ellos debe ser especicado.
Accin.
El rango de tareas que pueden ser llevadas a cabo por una accin se especica como sus
opciones. Las acciones pueden ser la modicacin, creacin, eliminacin de un documento, o
inicio de tareas dentro del proceso.
3.3.2. Representacin de una regla ECA con CCPN
Las reglas ECA se modelan a travs de la CCPN de acuerdo a la siguiente interpretacin:
1. Los eventos se modelan como lugares de entrada de una transicin
2. Las condiciones se modelan como condiciones agregadas a las transiciones.
3. Las acciones se denen en una transicin y su resultado se reeja en lugares de salida
de esa transicin.
4. Las reglas ECA en s mismas se mapean en transiciones.
5. El disparo de la regla corresponde al disparo de la transicin.
6. La deteccin de eventos se modela con tokens iniciales.
46 Redes de Petri
Regla ECA:
En: evento (e
i
)
Si: condicin (c
i
)
Entonces: accin (a
i
)
p1
t1
p2
Regla ECA
CCPN
Regla ECA:
En: evento (e
i
)
Si: condicin (c
i
)
Entonces: accin (a
i
)
p1
t1
p2
Regla ECA
CCPN
Regla ECA:
En: evento (e
i
)
Si: condicin (c
i
)
Entonces: accin (a
i
)
p1
t1
p2
Regla ECA
CCPN
Figura 3.8: Representacin con CCPN de una regla ECA
En el siguiente captulo se presentan la denicin y los elementos originales de la CCPN,
adems de ciertos elementos agregados con el n de extender su denicin para modelar
los conceptos de workow. En [20] se presenta la denicin de las CCPNs utilizadas en el
contexto de bases de datos activas.
Si bien, el uso de reglas ECA pudiese parecer propio de las bases de datos activas, existen
trabajos en los que se proponen enfoques basados en reglas ECA para tratamiento de excep-
ciones en workows [24], [29] o para ejecucin automtica de procesos de workow [30], [31].
En el siguiente captulo presentamos una propuesta de modelado de procesos de workow
basada en el enfoque de reglas ECA utilizando una extensin de las redes de Petri coloreadas
condicionales.
En este captulo se present la teora relacionada a redes de Petri, se presentaron las
condiciones bsicas para habilitacin y disparo de transiciones en una PN y en una CPN con
lo que es posible generar el juego de tokens que visualmente proporciona la perspectiva de
ejecucin del sistema modelado. Tambin permite obtener una perspectiva de los estados que
3.4 Comentarios nales 47
alcanza el sistema, adems de que esta parte visual de las PN permite obtener modelos ms
reales de los sistemas representados. Adicionalmente, se tiene la ventaja de tener una semn-
tica formal con lo que es posible validar y vericar los modelos obtenidos con la utilizacin
de herramientas matemticas. En la ltima seccin se present una breve introduccin de
lo que son las CCPN como modicacin de las redes de Petri coloreadas. En la siguiente
seccin se estudian con ms detalle y se presenta su utilizacin para el modelado de procesos
de workow.
48 Redes de Petri
Captulo 4
WfCCPN para modelado de procesos
de workow
En este captulo se presenta la extensin de CCPNs la cual se propone como metodologa
para modelar procesos de workow; se presenta la denicin y los elementos de la CCPN
extendida, as como tambin el enfoque sugerido para el modelado. Adems se muestran
las posibles formas de representar los conceptos de workow presentados en el captulo 2 y
nalmente se presenta la implementacin de veinte patrones de ujo de control identicados
en [15]. stos son utilizados en la actualidad como marco de evaluacin para lenguajes o
metodologas utilizadas para modelar procesos de workow.
4.1. Por qu no utilizar CPN para modelar workow?
Antes de presentar la denicin y los elementos que conforman la extensin de CCPN
propuesta, es conveniente responder a la siguiente pregunta: Por qu no utilizar simplemente
las redes de Petri Coloreadas para modelar procesos de workow?
Las CPNs originales no son completamente convenientes para el modelado de procesos de
workow, como se menciona en [8], [9] debido a que las CPN han sido sometidas al marco de
evaluacin conocido como patrones de workow, los resultados de lo anterior demuestran que
con CPN no pueden ser implementados cinco patrones. En [9] se identican los problemas
que surgen al tratar de modelar esos patrones; en este captulo se proporciona una posible
solucin utilizando la extensin de CCPN que al igual que las CPN son redes de Petri de alto
nivel. Es decir consideran datos, tiempo y caractersticas de jerarqua. Adems de lo anterior,
50 WfCCPN para modelado de procesos de workow
el enfoque sugerido en esta tesis se basa en representar el workow desde un enfoque de reglas
ECA, por lo cual es necesario representar las estructuras de reglas ECA relacionadas entre
s, al considerar esto con una CPN sus elementos resultan insucientes [20], sobre todo al
considerar reglas ECA con eventos compuestos.
Las diferencias ms importantes entre una CPN y una CCPN son las siguientes: En primer
lugar, en una red de Petri coloreada los eventos no se consideran [20], mientras que en una
CCPN un evento es parte de una regla ECA; estos eventos son representados con lugares
de entrada de una transicin. Las condiciones en una CPN por lo general son representadas
en los arcos, adems de que las acciones son representadas a travs de transiciones [28]. Es
a travs de las transiciones como en una CPN se modelan los estados que posee el sistema,
mientras que en una CCPN los estados son modelados como en una PN bsica, es decir
utilizando lugares.
Otra diferencia es que en los arcos de la CCPN no se contemplan las expresiones que se
utilizan en las CPN. Con esto se logra aumentar la exibilidad en el modelo, sin embargo se
pierde un poco el control de los datos que pueden circular en la red, dejando esta tarea a las
condiciones utilizadas en las transiciones de una CCPN. Esto necesario al no tener restriccin
en los datos que pueden ser denidos al momento de modelar un proceso de workow, en el
que sus datos pueden ser de cualquier tipo y pueden pertenecer a cualquier tipo de contexto
al ser procesos genricos de negocios.
Por las razones anteriores, puede concluirse que las CPN no proporcionan todos los ele-
mentos que un lenguaje de modelado de procesos de workow. Sin embargo, las CPNs son
una herramienta que ha sido utilizada por varios aos en el modelado de sistemas dentro
de las reas acadmicas as como en la industria, y perfectamente pueden modelar cualquier
tipo de sistema. Sin embargo, en este trabajo nos enfocamos en detalles especcos del mod-
elado de procesos de workow que han sido expuestos en [8], [9], [20], trabajos que permiten
sugerir una propuesta basada en una modicacin de las CPNs, es decir las Redes de Petri
Coloreadas Condicionales. A continuacin se presenta la extensin realizada a las CCPNs
que son utilizadas como propuesta de modelado en esta tesis.
4.2 Extensin a las redes de Petri coloreadas condicionales 51
4.2. Extensin a las redes de Petri coloreadas condi-
cionales
En el captulo 2 se presentaron las diferentes perspectivas en que se modela un proceso
de workow; stas son las siguientes: la perspectiva del ujo de control, la perspectiva de
datos, la perspectiva de recursos y la perspectiva operacional. El trabajo realizado en esta
tesis se encuentra delimitado en la perspectiva de ujo de trabajo y de manera parcial en la
perspectiva de datos. La perspectiva de datos se modela con la informacin que es posible
transportar en los tokens de la CCPN; es as como el alcance y visibilidad de los datos
manejados en los modelos obtenidos es nicamente local. Cabe recordar que este trabajo no
contempla la representacin y ejecucin del workow modelado. Por lo tanto, no es necesario
contemplar por el momento datos externos al modelo que pudiesen incidir en el ujo de la
informacin de ste. Por esta razn no se provee un soporte total para la perspectiva de
datos, esto se explica con ms detalle en las siguientes sub secciones. Con el n de diferenciar
el uso de las CCPN para modelar bases de datos activas y para modelar workow, adems
de los elementos aadidos a la CCPN original, se consider conveniente referirse de manera
diferente a las CCPN en este trabajo, por lo tanto de aqu en adelante se agrega el prejo
Wf, de tal modo que la extensin a las CCPN ser referida como: WfCCPN (Workow
Conditional Colored Petri Nets).
Utilizando las WfCCPN, es posible modelar la perspectiva de ujo de control sin necesidad
de abstraer los datos de control. Estos datos son los que deciden el ujo de la informacin
en un proceso de workow. En [13] se realiza la modelacin abstrayendo datos de control,
datos temporales y eventos externos. Actualmente son pocas las metodologas o lenguajes que
permiten especicar ms de una perspectiva dentro de un solo modelo. Uno de estos lenguajes
es YAWL [9], el cual est basado en redes de Petri; con WfCCPN es posible modelar las dos
sin perder la relacin entre el ujo de control y los datos que viajan a travs del ujo del
proceso. Esto se logra principalmente por la interpretacin de los elementos visuales de la
WfCCPN, los cuales ayudan a mantener la perspectiva a pesar de que el modelo crezca
considerablemente al ser ms detallado el modelo del sistema, en este caso del proceso de
workow.
En la siguiente seccin se presenta la denicin y los elementos que componen una WfC-
CPN.
4.3. WfCCPN
4.3.1. Elementos
Los elementos que conforman una WfCCPN se muestran en la gura 4.1.
Lugares
Transiciones
Arcos
a) Primitivo
b) Compuesto
c) Copia
d) Virtual
e) Subred
f) Instancia
g) Regla
h) Copia
i) Compuesta
j) Tiempo
k) Normal
l) Inhibidor
Figura 4.1: Elementos de una WfCCPN
Lugares.
Los lugares de una WfCCPN son clasicados en los siguientes tipos: primitivo, virtual,
copia, compuesto, subred e instancia. En la gura 4.1 se muestra como se representan cada
uno de stos. Un lugar primitivo es similar a un lugar de una red de Petri bsica aunque
ste posee un dominio de color. Un lugar compuesto es utilizado para almacenar tokens con
colores compuestos (i.e. crear un color a partir de atributos de diferentes colores) y para
reejar el resultado de una accin, stos tambin se utilizan para vericar plazos temporales
(deadline, en ingls). Los lugares copia se utilizan cuando una tarea es activadora de ms
de una regla ECA. De esta manera, es posible la activacin de varios eventos a partir de
4.3 WfCCPN 53
una tarea o de una accin, lo anterior es similar a un evento de multidifusin (broadcast,
en ingls). Un lugar virtual tiene la capacidad de almacenar cualquier tipo de color. Un
lugar subred se utiliza para crear el modelo de forma jerrquica permitiendo as tener un
modelo con varios niveles de profundidad, se utiliza el enfoque de renamiento de lugares en
contraste con el renamiento de transiciones que se utiliza en redes de Petri coloreadas [27].
Este tipo de lugares slo posee una transicin de entrada y nicamente una transicin de
salida. Finalmente un lugar instancia permite modelar un nmero n de instancias de una sub
red, permitiendo modelar sub-procesos. En WfCCPN una etiqueta es aadida a cada lugar,
la cual permite conocer qu interpretacin tiene con relacin a la representacin de una regla
ECA.
Transiciones.
Las transiciones son: regla, copia, virtual y tiempo. La gura 4.1 muestra su representacin
grca. Una transicin regla permite denir condiciones entre lugares que representan even-
tos, y lugares que representan acciones. Adems en la transicin regla se almacena la accin
que se realizar si la regla se dispara, de la cual su resultado ser representado por su lugar de
salida, es decir, el lugar que representa la accin de la regla ECA. Las transiciones compues-
tas son utilizadas para generar eventos compuestos a partir de eventos primitivos, tambin
permiten denir nuevos colores de tokens, y sirve tambin para vericar plazos temporales;
Las transiciones copia se utilizan para conectar lugares copia. Finalmente, una transicin
tiempo permite denir intervalos temporales vlidos para su activacin o en su lugar permite
denir un retardo de disparo.
Arcos.
Los arcos en una WfCCPN son dos: el arco bsico de una PN y el arco inhibidor. Un arco
inhibidor permite tener el siguiente comportamiento en la red: La transicin que es conectada
con un lugar de entrada a travs de un arco inhibidor nicamente se activar cuando en el
lugar no existan tokens, es decir si existe al menos un token la transicin nunca ser activada
a pesar de que cumpla la condicin bsica de activacin de la PN. Cabe mencionar que la
funcin guardia de los arcos en una red de Petri coloreada que permiten restringir el paso de
determinados colores a travs de estos; en WfCCPN no estn presentes.
Tokens
En este trabajo un token adems de poseer un color (datos), contiene adems dos estampas
de tiempo, una para almacenar el momento en el tiempo en que es creado y la otra almacena el
tiempo en que es modicado su color, ya sea su estructura o en la informacin de los atributos
del token. La estampa de tiempo es de la forma: a no : mes : dahora : minutos : segundos
4.3.2. Reglas de disparo
En la WfCCPN los disparos se llevan a cabo de la siguiente manera: una transicin copia se
dispara si la condicin bsica de PN se cumple. Sin embargo, las dems transiciones requieren
que una condicin adicional sea evaluada a verdadero. Una transicin compuesta requiere que
su lgica y su condicin temporal sea satisfecha en caso de que hayan sido denidas. Una
transicin tiempo requiere que el intervalo de tiempo sea satisfecho y nalmente una transicin
de tipo regla necesita que su condicin lgica sea evaluada verdadero.
La denicin formal se basa en el concepto matemtico de multiconjunto, otros conceptos
como son el tipo de elemento, tipo de variable Type(v), el tipo booleano , que son propios
de las redes de Petri coloreadas y estn presentes en las WfCCPN. Se presenta a continuacin
la estructura formal de la WfCCPN.
Denicin 4.1 Para la denicin se utiliza la siguiente notacin:
B=una variable booleana con los valores {verdadero, falso}
Denicin 4.2 Una WfCCPN es una 11-tupla
WfCCPN = {
P
, P, T, A, N, C, Con, Accion, D, , I}
donde
(1)
P
es un conjunto no vaco de tipos, llamados conjunto de colores.
(2) P es un conjunto nito de lugares. Para una mejor representacin grca, P es divi-
dido en varios subconjuntos,
P = P
primitivo
P
compuesto
P
virtual
P
copia
P
subred
P
instancia
y
P
preetiquetados
= {(P
preetiquetados_primitivos
P
pritmitivos
) (P
preetiquetados_virtuales

P
virtuales
)
4.3 WfCCPN 55
donde P
primitivo
, P
compuesto
, P
virtual
y P
copia
son los conjuntos de lugares primitivos, com-
puestos, virtuales y copia, P
subred
y P
instancia
son el conjunto de lugares subred e instancia que
al ser renables pueden contener una denicin WfCCPN completa dentro de s, adems se
tienen los subconjuntos de lugares pre-etiquetados P
preetiquetados
que son lugares con una
funcin especial predenida, pero con las mismas caractersticas de los lugares virtuales,
P
preetiquetados_virtuales
, el mismo caso que los primitivos pre-etiquetados P
preetiquetados_primitivos
.
(3) T es un conjunto nito de transiciones. T es dividido en cuatro subconjuntos,
T = T
regla
T
copia
T
compuesta
T
tiempo
donde T
regla
, T
copia
, T
compuesto
y T
tiempo
son el conjunto de transiciones regla, copia, com-
puesta y tiempo.
(4) A es un conjunto de arcos tales que
P T = P A = T A =
A = A
normal
A
inhibidor
, donde A
normal
y A
inhibidor
representan el conjunto de arcos nor-
males e inhibidores respectivamente.
(5) N es una funcin nodo. sta es denida de A hacia P T T P.
(6) C es una funcin de color. sta es denida de P hacia
P
.
(7) Con es una funcin condicin. Este es cualquiera de las transiciones T
regla
o T
compuesta
hacia expresiones tales que
t T
rule
: [Type(Con(t)) = B]
donde Con es la funcin que evala la condicin regla
t T
comp
: [Type(Con(t)) = B]
donde Con es la funcin que evala la condicin temporal
(8) Accion es una funcin. Esta es denida de T
rule
y T
compuesta
hacia expresiones tales
que:
t T
regla
T
compuesta
, p t : [Type(Accion(t)) = C(p)
MS
]
(9) D es una funcin de tiempo.
t T
tiempo
: [Type(Intervalo(t)) = B]
sta es denida de T
timepo
hacia un intervalo de tiempo [d
1
, d
2
]; donde t T
tiempo
, y donde
se tiene un d
1
, d
2
que son el intervalo inicial y el nal respectivamente.
t T
tiempo
: [Type(Retardo(t)) = B]
Esta es denida de T
tiempo
hacia un retardo de tiempo [d]; donde t T
tiempo
, y
donde d es un retardo especicado en unidades de tiempo diferentes a 0.
(10) es una funcin de estampa de tiempo.
= {
creacion

modificaci on
}
stas son denidas de M(p) hacia {0} R
+
, las cuales se asignan a cada token en el
lugar p. Una estampa de tiempo, ya sea de creacin del token o de modicacin de ste, se
corresponde con el reloj natural de la forma: a no : mes : da hora : minutos : segundos
(11) I es una funcin de inicializacin. sta es denida de P hacia expresiones cerradas
tales que
p P : [Type(I(p)) = C(p)
MS
]
4.3.4. Reglas ECA modeladas con WfCCPN
En la denicin de una conjunto de reglas ECA relacionadas a travs de una WfCCPN, se
toma a cada una de las reglas para convertir sus elementos en elementos de la WfCCPN. Dado
un conjunto de reglas ECA R = {r
1
, r
2
, ..., r
n
}, para cada regla r
i
(ei, ci, ai), i = 1, 2, ..., n,
el evento e
i
es modelado con una estructura de WfCCPN. En el caso de eventos primitivos
se utilizan lugares p P
prim
, y para el caso de eventos compuestos se generan estructuras
correspondientes a cada evento compuesto. La condicin de la regla c
i
se almacena dentro
de una transicin t T
regla
T
compuesta
la cual ser evaluada durante el proceso de disparo
de la transicin t. La accin de la regla ECA es una operacin que reeja la modicacin
de los datos que pasan a travs de la transicin (en la transicin t se adjunta la denicin
de la accin) y sta es representada por un lugar p P
primitivo
P
compuesto
de la WfCCPN;
esta operacin puede ser cualquiera que se encuentra dentro de la fuente de eventos. En la
gura 6.1, se ilustra la representacin en WfCCPN del evento, la condicin y la accin de
una regla ECA. El lugar p
1
que representa al evento e
i
de la regla puede ser de cualquier tipo
(p
1
P
prim
P
comp
P
virtual
P
copy
). La condicin c
i
se almacena dentro de una transicin
t
1
T
regla
T
compuesta
. En el caso de tener un intervalo vlido para la ejecucin de la regla, ste
es denidio utilizando t
1
T
tiempo
.Para vericar fechas lmites es posible denirlas utilizando
una transicin t
1
T
compuesta
. Finalmente, la accin de la regla ECA a
i
se traduce en un lugar
de salida p
2
P
prim
de t, en t se dene la funcin T
Accion
. Podemos decir que la regla ECA
est siendo representada por t, porque en t se conocen los elementos de la regla: el evento es
su lugar de entrada, la condicin est almacenada en ella as como la accin a realizarse y el
resultado de la accin es representada en su lugar de salida.
4.4 Representacin de conceptos bsicos de un workow 57
4.4. Representacin de conceptos bsicos de un work-
ow
En la seccin 2.2 se present la denicin de cada uno de los elementos (proceso, caso,
tarea, usuario, etc.) que forman parte de un proceso de workow. A continuacin se muestra
la manera de interpretarlos a travs de WfCCPN. En su mayor parte las descripciones se
apoyan de un ejemplo de workow, el cual se reere al proceso genrico que se lleva en la
seleccin de artculos para publicacin en congresos cientcos.
4.4.1. Procesos y casos
El concepto principal en workow es el proceso; un proceso es representado con una
estructura WfCCPN. Los casos son instancias de un proceso, por lo tanto con la ejecucin
del proceso se tendr un caso del proceso de workow. El proceso engloba los conceptos que
en las subsecuentes secciones se presentan. Ejemplo de un proceso es el siguiente: El proceso
que sigue un artculo enviado por un autor para su publicacin en un congreso cientco. Un
caso de ese proceso sera el envo en particular por cierto autor. De esta manera, por cada
autor que enve un artculo se tendr un caso del proceso; en este trabajo el caso es referido
como instancia del proceso.
4.4.2. Tareas
Un proceso puede ser dividido en tareas para su anlisis, estas son atmicas porque
no pueden ser divididas. Adems estas tareas modican los datos en el workow. Con la
ejecucin de una tarea es posible que se provoque la activacin y ejecucin de otras. En redes
de Petri, hay dos opciones para modelar una tarea: como una transicin o como un lugar [7].
La mayora de los enfoques basados en redes de Petri utilizan la primera opcin. Algunos
de stos son: [13], [14], [9], [12], [11], [10]. Con WfCCPN una tarea se representa utilizando
cualquier tipo de lugar excepto los lugares de tipo sub_red e instancia, se realiza de esta
manera debido al enfoque de representacin de una regla ECA mostrado anteriormente. De
esta manera, el modelo obtiene temporalidad en las tareas. Es decir en su realizacin puesto
que con la presencia de un token en un lugar su disparo no debe ocurrir inmediatamente,
sino hasta que la condicin lgica de la transicin se cumpla, situacin que no es posible
tomando en cuenta nicamente la condicin bsica de una red de Petri. Adems, mediante
transiciones de tipo tiempo, es posible retardar la realizacin o nalizacin de la tarea segn
la interpretacin dada.
OCURRE
evento
SI condicin
ENTONCES
accin
Tarea1
Accin/Tarea2/Estado
Condicin
Tarea1 Tarea2
Accin/Tarea3
Condicin
Tarea1
Accin
Tarea2
Accin
a) c) b)
Figura 4.2: Representacin de tareas
La gura 4.2 presenta las posibles representaciones para una tarea utilizando diferentes
elementos de la WfCCPN. La gura. 4.2 a) muestra la situacin ms simple, la tarea es
activada con la presencia de tokens en el lugar de entrada. Si la condicin es satisfecha la
tarea es realizada y la accin denida en la transicin es reejada en el lugar de salida, en
ese punto la informacin del token pudo haber sido modicado por la accin. El lugar de
salida puede representar una nueva tarea o un nuevo estado en el workow. En la gura 4.2
b) se muestra la situacin en que la nalizacin de dos tareas es necesaria para que se lleve
a cabo la siguiente tarea o para que se realice una determinada accin. De igual manera que
la situacin anterior, en sta, la informacin del token puede sufrir cambios. En reglas ECA
existen relaciones entre reglas, eso puede verse en situaciones en que dos reglas compartan
el mismo evento. Tambin dos reglas estn relacionas si una accin es la misma para dos
eventos. Esta situacin se muestra en la gura 4.2 c).
Ciertas tareas de un workow pueden ser consideradas como imprescindibles, estas tareas
son las que inicializan y nalizan el proceso. Para estas tareas se predenieron lugares a los
que se denomina lugares pre-etiquetados, los cuales se muestran en la gura 4.3.
En la gura 4.3 a) se muestran los lugares virtuales pre-etiquetados: inicio, sub_inicio
y diferido, para iniciar el proceso principal y subprocesos del workow respectivamente.
Adems con el lugar diferido, es posible colocar tokens en tiempo de ejecucin con el n
a) Lugares virtuales pre-etiquetados b)Lugares primitivos pre-etiquetados
inicio
fin sub_fin cancelado
diferido sub_inicio
Figura 4.3: Lugares pre-etiquetados
de modelar eventos externos o acciones realizadas por usuarios del workow. Tambin son
presentados tres lugares primitivos pre-etiquetados: n, sub_n y cancelado para acciones
de nalizacin y cancelacin del proceso de workow. stos son mostrados en la gura 4.3
b). Los lugares n y sub_n se utilizan para nalizar el proceso principal y subprocesos
respectivamente, mientras que cancelado que se utiliza en combinacin con los dos anteriores
para la cancelacin del proceso completo o cancelacin de subprocesos.
4.4.3. Constructores bsicos de enrutamiento
La WfMC [21] dene los constructores bsicos para construir las posibles rutas que toma la
informacin dentro de un proceso de workow. Con estos constructores es posible representar
la perspectiva de ujo de control descrita en el captulo 2. Para este trabajo se denieron
los constructores por medio de estructuras WfCCPN. stos permiten incluir informacin de
control ya que pueden utilizarse tokens coloreados. Los constructores se muestran en la gura
4.4.
Secuencia. Este constructor modela la situacin ms natural y simple dentro de un
proceso workow, modela una tarea que se ejecuta slo hasta que la tarea que le precede
ha sido ejecutada. En la gura 4.4 a) se muestra la manera en que este constructor es
implementado. La tarea o evento que se representa con el lugar B ser ejecutada una vez
que la tarea A haya sido realizada. En el caso de la PN, cuando la transicin t sea activada
y cumpla con la condicin lgica sta ser disparada colocando un token en el lugar B que
representa la realizacin de su tarea asociada.
AND-Split. Con este constructor se modelan principalmente situaciones de paralelismo.
La gura 4.4b) muestra la estructura en WfCCPN que lo implementa; cuando un token llega
a la transicin t T
copia
ste es replicado hacia los lugares de salida, los cuales pueden ser
p P
copia
, P
virtuales
. De esta manera, se tendr una copia del token original en cada lugar de
a) Secuencia
b) AND-Split
e) XOR/OR-Join
c) XOR/OR Split
d) AND-Join
A
B
A
A
A
B
B
B
A
B
Figura 4.4: Implementacin de los constructores de enrutamiento a travs de WfCCPN
salida con su respectivo ujo de control. En la gura se muestra de que manera las tareas A
y B se ejecutarn de manera paralela.
AND-Join. Cuando dos o ms tareas se estn ejecutando de manera paralela, llega un
punto en el workow en que convergen en un hilo de ejecucin, es decir con el resultado o
condicin de haberse ejecutado previamente. Posteriormente es posible ejecutar otra tarea o
bien, activar un evento o ejecutar una accin [15]. La gura 4.4 d) muestra la implementacin
de este constructor; la transicin t T
compuesta
permite realizar una sincronizacin de los
tokens que le llegan. Esta sincronizacin puede realizarse simplemente con permitir el paso
a un determinado token, o la generacin de tokens con nuevos colores los cuales pueden
formarse a partir de los datos de los tokens que hubiesen llegado a la transicin t.
XOR/OR-Split. En [15] el XOR se distingue del OR normal, siendo el XOR la situacin
en la que una y nicamente una ruta puede ser tomada en el ujo del workow, por el
contrario un OR es la situacin en que ms de una ruta o incluso ninguna puede ser elegida
para seguirse en el proceso. Esta implementacin se realiza de igual manera con WfCCPN,
ya que con la condicin en cada t T
regla
decide cuntas rutas son tomadas, por lo tanto es
responsabilidad del modelador establecer si es un XOR o un OR el constructor.
OR-Join. La decisin que puede tomar una o varias rutas de entre un nmero elegible
se realiza a travs de las condiciones establecidas en cada una de las transiciones t T
regla
.
En la gura 4.4 e) se presenta este constructor.
4.4.4. Datos
En WfCCPN la representacin de datos se realiza de igual manera que en CPNs es
decir a travs de colores. Para cada workow es posible denir un conjunto
P
de colores,
el cual representa los datos del proceso modelado. Un color posee un nombre por el cual es
identicado, y un conjunto de atributos que pueden ser de diferentes tipos alfanumricos,
numricos, e incluso otros colores. Cada atributo contiene su respectivo valor y stos pueden
ser modicados a travs del conjunto de Acciones de la WfCCPN. Adems, a partir de
estos atributos es posible denir las condiciones para el conjunto de transiciones t T
regla
T
compuesta
.
4.4.5. Personas, Roles y Grupos
Las personas, roles y grupos son representados de manera parcial. Estos recursos son repre-
sentados de manera completa en la perspectiva organizacional. Sin embargo, con WfCCPN es
posible representar un usuario con un lugar virtual debido a la capacidad de almacenar tokens
de cualquier color sin restriccin alguna. Los roles y los grupos pueden ser representados a
travs de los atributos de los colores que pueden representar a una persona. Utilizando un
lugar virtual es posible representar, por ejemplo, a los revisores del ejemplo.
4.4.6. Estados
Con WfCCPN un estado es representado a travs de cualquiera de los siguientes tipos de
lugares p P
primitivo
P
compuesto
P
virtual
P
copia
. Utilizando el ejemplo del envo de artculos
presentamos algunos posibles estados del workow; recordando que un estado identica la
situacin del sistema o de un documento en un momento dado, adems de proveer informacin
sobre el proceso desde alguna de las siguientes dos perspectivas:
Los datos que contiene en ese momento algn lugar, por ejemplo un lugar que represente
el estado del artculo enviado, podra ser representado con tres lugares uno para el estado
aceptado, otro para el estado aceptado condicionalmente y otro ms para los artculos
con estado de rechazados.
La etapa en que se encuentra el proceso. Por ejemplo si el proceso se encuentra en la
etapa de recepcin de artculos, o si ya concluy esa fase, es posible que se encuentre
en la etapa de revisin de artculos, o en la etapa de recibir las versiones nales de los
artculos aceptados.
4.4.7. Condiciones
Las condiciones en una WfCCPN son representadas a travs de transiciones de tipo regla
y de tipo compuestas. stas permiten modicar el ujo natural de la informacin y llevar
a ciertos estados que pueden ser deseados dentro del proceso. Adems, las condiciones en el
enfoque de modelado con reglas ECA es fundamental.
4.4.8. Plazos y Caractersticas temporales
En WfCCPN las transiciones tiempo y las compuestas proporcionan caractersticas de
tiempo, y utilizndose con las estampas de tiempo de los tokens, pueden vericar condiciones
de fechas lmite (deadlines). Adems con transiciones tiempo es posible denir intervalos
vlidos para la activacin de la transicin. As, se pueden modelar tareas que necesitan de
algn tiempo antes de estar disponibles para su ejecucin. Recurriendo al ejemplo del envo
de artculos a un congreso, la primera condicin temporal que puede ser modelada es la fecha
lmite para el envo de artculos. El token del color que representa el artculo es evaluado a
travs de su estampa de tiempo de creacin para decidir si est dentro del tiempo especicado.
4.4.9. Modelos jerrquicos
En la vida real muchos procesos que se modelan son grandes y modelarlos con redes
de Petri puede dar como resultado redes bastante grandes como para ser bien manejadas y
apreciadas. Es por eso necesario descomponer el modelo en varios sub modelos. Esta idea en
redes de Petri es adoptada de la programacin estructurada y es posible representar con un
lugar o con una transicin otra red de Petri, a esto se le conoce como renamiento de lugar
o de transicin. En redes de Petri coloreadas se utiliza el renamiento de transiciones [27].
Con WfCCPN, se utiliza el renamiento de lugares debido al enfoque de utilizar lugares
para representar tareas. Por tal razn, se utilizan los lugares
p
P
subred
, stos fueron presen-
tados en la gura 4.1 e).
En la gura 4.5 se muestra de manera grca un lugar subred y el concepto que representa.
Dentro del lugar P
1
que pertenece a una red WfCCPN se tiene denida otra red WfCCPN
4.5 Patrones de workow 63
I a
A
O a
Figura 4.5: Sub-redes WfCCPN dentro de lugares de tipo sub-red
que cuenta con uno de entrada P
entrada
y nicamente un lugar de salida P
salida
. Este tipo de
lugares puede ser de salida de cualquier tipo de transicin. Sin embargo, slo puede ser lugar
de entrada para una sola transicin de tipo regla como se muestra en la gura.
4.4.10. Mltiples instancias
Uno de los principales requerimientos en un modelo de workow as como para una her-
ramienta de modelado es la denicin de mltiples instancias de un caso. Es decir que un
caso pueda ser ejecutado n veces dentro del mismo proceso principal que es modelado. La
capacidad de modelar mltiples instancias en WfCCPN se bas en [32], [9]. Con WfCCPN
se utiliza un lugar especial llamado instancia ste fue mostrado en la gura 4.5 f). Este
tipo de lugares contiene la denicin de una red de petri de la misma forma que un lugar
de tipo subred. Cada token que llega a un lugar instance crear y ejecutar una instancia
por separado de la sub red. Es decir, si llegan cuatro tokens, tendremos cuatro instancias
ejecutndose en paralelo. Este lugar nicamente puede tener una transicin de entrada y una
transicin de salida.
4.5. Patrones de workow
Los patrones de workow son utilizados como framework de evaluacin, ste ha sido bi-
en adoptado por los vendedores de sistemas de workow, evaluando sus productos con este
framework. En [15] se presentan estos patrones con la evaluacin de algunos productos de soft-
ware, se encuentra una breve evaluacin de la expresividad de modelado de cada herramienta
de software probado. Vale la pena mencionar que el trmino: expresividad de modelado no
es lo sucientemente rigorista ya que puede ser subjetivo, as como subjetivos son los modelos
obtenidos con cualquier herramienta de modelado, debido a una razn sencilla: es posible
que dos personas modelen de manera diferente el mismo proceso. Se utiliz este framework
de evaluacin debido a la aceptacin que posee y los resultados que pueden encontrarse en
[33], [9], [8], [32], [16], [32].
En [15], [9], [16] se presentan diversas evaluaciones a los sistemas administradores de
workow (WfMS, Workow Managament Systems) ms importantes al momento de escribir
esta tesis. Los resultados muestran que los siguientes WfMSs: COSA, SAP/R3, InConcert,
iFlow, MQ Series, Staware, Visual Worko, Domino workow, Meteor y otros ms nica-
mente soportan entre once y catorce patrones en promedio. El mismo resultado se tiene con
estndares de modelado tales como: XPDL, BPEL4WS, BPML, WSFL, XLANG, WSCI y
UML 2.0.
Los patrones de workow en ujo de control son veinte, divididos en los siguientes seis
grupos:
Patrones bsicos: (1) Secuencia, (2) Split paralelo, (3) Sincronizacin, (4) Eleccin
exclusiva, (5) Mezcla simple.
Sincronizacin y ramicaciones avanzadas: (6) Mltiple eleccin, (7) Mezcla con sin-
cronizacin, (8) Mezcla mltiple (9) Discriminador, (9b) N-salen-de-M Joins.
Patrones estructurales: (10) Ciclos arbitrarios, (11) Terminacin implcita.
Patrones de Mltiples Instancias: (12) MI sin sincronizacin, (13) MI con conocimiento
en tiempo de diseo a priori, (14) MI con conocimiento en tiempo de ejecucin a priori,
(15) MI sin conocimiento en tiempo de ejecucin a priori.
Patrones basados en estados: (16) Eleccin diferida, (17) Enrutamiento paralelo de
interllegada, (18) Entrega de producto.
Patrones de cancelacin: (19) Actividad cancelada, (20) Caso cancelado.
En [9] se presenta una perspectiva de los problemas que surgen al intentar modelar es-
tos patrones con redes de Petri de alto nivel (CPN). WfCCPN son redes de Petri de alto
nivel; por esta razn se prest especial atencin en vericar dichos problemas y en realizar
su implementacin a travs de estructuras WfCCPN. Los resultados obtenidos permitieron
demostrar que ciertos patrones pueden ser modelados a travs de las caractersticas bsicas
de la WfCCPN tal es el caso de los patrones 5 y 6. Sin embargo, en otros patrones el problema
se resolvi con los elementos que fueron aadidos a la CCPN original. La tabla de la gura
4.6 que fue publicada en [9] muestra una comparacin del estndar XPDL de la WfMC para
modelar de manera gramatical (no grca), tambin la nueva versin UML 2.0. Un estudio
sobre ste se encuentra publicado en [8]. Adems el estudio de redes de Petri de alto nivel
y del lenguaje YAWL estn presentes en esa tabla. La tabla original fue modicada para
anexar los resultados obtenidos con WfCCPN.
+ + + + - 8(mezcla mltiple)
+ + - + - 20(cancela-casos)
+ + +/- + - 19(cancela-actividades)
+ + + - - 18(entregables)
+ + + - - 17(enrut-paral-inter)
+ + + + - 16(eleccin diferida)
+ + - - - 15(mi-sin-c-priori)
+ + - + - 14(mi-priori-t-ejecucin)
+ + + + + 13(mi-priori-t-diseo)
+ + + + + 12(mi-sin sincronizacin)
+ - - + + 11(terminacin implicita)
+ + + + + 10(ciclos arbitrarios)
+ + - + - 9(discriminador)
+ + - - + 7(sincronizacin mlt)
+ + + + + 6(eleccin mltiple)
+ + + + + 5(mezcla-simple)
+ + + + + 4(eleccin-mltiple)
+ + + + + 3(sincronizacin)
+ + + + + 2(split-paralelo)
+ + + + + 1(secuencia)
WfCCPN YAWL High-level Petri nets CPN) UML 2.0 XPDL Patrn
+ + + + - 8(mezcla mltiple)
+ + - + - 20(cancela-casos)
+ + +/- + - 19(cancela-actividades)
+ + + - - 18(entregables)
+ + + - - 17(enrut-paral-inter)
+ + + + - 16(eleccin diferida)
+ + - - - 15(mi-sin-c-priori)
+ + - + - 14(mi-priori-t-ejecucin)
+ + + + + 13(mi-priori-t-diseo)
+ + + + + 12(mi-sin sincronizacin)
+ - - + + 11(terminacin implicita)
+ + + + + 10(ciclos arbitrarios)
+ + - + - 9(discriminador)
+ + - - + 7(sincronizacin mlt)
+ + + + + 6(eleccin mltiple)
+ + + + + 5(mezcla-simple)
+ + + + + 4(eleccin-mltiple)
+ + + + + 3(sincronizacin)
+ + + + + 2(split-paralelo)
+ + + + + 1(secuencia)
WfCCPN YAWL High-level Petri nets CPN) UML 2.0 XPDL Patrn
Figura 4.6: Patrones de ujo de control en diferentes metodologas de modelado de workow
Cabe mencionar que no se presenta una denicin en extenso de cada patrn. Sin embargo
en [33], [16] es posible ampliar la informacin sobre stos. A continuacin se muestra la
implementacin de cada patrn utilizando elementos de una WfCCPN.
4.5.1. Patrones de ujo de control bsicos
Estos patrones son implementados de manera natural por todos los sistemas de workow
y lenguajes de modelado. Por esta razn se presenta de manera breve la implementacin
utilizando WfCCPN. No se muestra de manera grca ya que con los constructores bsicos
de enrutamiento denidos por la WfMC son sucientes para modelar estos patrones bsicos.
Los constructores bsicos fueron mostrados en la gura 4.4.
Secuencia.
Este patrn aparece cuando es necesario que una actividad sea completada una para
que otra actividad, evento o accin sea iniciada. Con WfCCPN se implementa a travs de
cualquier tipo de lugares utilizando cualquier tipo de transiciones que se conecten de manera
secuencial, en la gura 4.4 a) se muestra la implementacin de este patrn.
Paralelizacin
Este patrn permite ejecutar tareas en paralelo, la implementacin con WfCCPN es sim-
ilar al fork que se utiliza en los diagramas de actividad de UML. Utilizando el constructor
And-Split se obtiene el comportamiento de este patrn, que se muestra en la gura 4.4 b).
Sincronizacin.
Este patrn sincroniza dos o ms hilos de ejecucin, que se vienen ejecutando de forma
paralela. Desde la perspectiva de ujo de control el constructor AND-Join ya sea implcito
o explicito es suciente. Sin embargo, con WfCCPN adems de lograr la sincronizacin en
el ujo del workow, es posible aadir sincronizacin de datos al utilizar alguna de las Ac-
ciones que puede aadirse a las transiciones compuestas. En la gura 4.4 d) se muestra la
implementacin de este patrn.
Eleccin exclusiva.
Se elige una ruta de entre muchas que se tienen como alternativas. Con WfCCPN se
utiliza una transicin de tipo regla con su condicin asociada para cada una de las rutas
alternativas. Se denen las condiciones con el n de que un nico hilo de ejecucin sea
activado como resultado de la evaluacin de las condiciones; el constructor XOR-Split es
suciente para modelar este patrn, el cual se muestra en la gura 4.4 c).
Mezcla simple.
Este patrn mezcla dos rutas alternativas de ejecucin, y es implementado con el construc-
tor XOR-Join de la gura 4.4 e). Con WfCCPN se utiliza un lugar virtual para almacenar
tokens de cualquier color. Debido a que del OR-Join pueden provenir tokens de diferentes col-
ores, en las diferentes rutas que llegan, nuevamente es necesario denir en la transicin regla
las condiciones que permitan que la informacin arribe a un determinado hilo de ejecucin.
4.5.2. Ramicaciones y sincronizacin avanzada
A
C
B
A
C
B
a) Mezcla con
sincronizacin
b) Mezcla mltiple
Figura 4.7: Implementacin de los patrones: mezcla con sincronizacin y mezcla mltiple.
Eleccin mltiple.
Con este patrn es posible elegir n rutas de ejecucin de entre m alternativas (donde
m > n) [33]. Este patrn es implementado a travs del constructor OR-Split. En la gura 4.4
e), se muestra que cada posible ruta posee su propia transicin de tipo regla y stas permiten
seleccionar las rutas que deben seguir ejecutndose.
Mezcla con sincronizacin.
Este patrn considera la sincronizacin de varias rutas de ejecucin hacia un nico hilo
de ejecucin [33]. En la gura 4.7 a) se muestra la implementacin mediante WfCCPN. En
primer lugar se realiza la eleccin mltiple, en la gura 4.7 a) se representan tres tareas
las cuales convergen hacia una transicin compuesta, para posteriormente llegar a un lugar
compuesto. De esta manera es posible sincronizar la informacin de las tres tareas, utilizando
una funcin Accin que puede ser la creacin de un color nuevo con informacin relevante de
cada una de las tareas, o con la modicacin de los atributos en los colores de los tokens. En
[9] se menciona la siguiente razn como el problema al implementar este patrn con CPN:
La mezcla con sincronizacin no es soportada porque el diseador tiene que mantener la
referencia del nmero de hilos en paralelo y decidir s sincroniza o mezcla el ujo. Con
WfCCPN esto queda resuelto al contar con los lugares compuestos, ya que de esta manera se
implementa la sincronizacin, mientras que con transiciones copia es implementada la mezcla
mltiple, es decir se tiene una implementacin en particular para cada patrn. Ciertamente,
con CPNs slo es posible tener el comportamiento que con transiciones copia se tiene en
WfCCPN.
Mezcla mltiple.
Este patrn es mencionado en el problema de modelado con el patrn anterior, En este
patrn no existe sincronizacin, es decir puede pasar ms de una tarea hacia el hilo de
ejecucin simple en que convergen, debido a que se emplea una transicin de tipo copia. Este
patrn se muestra en la gura 4.7 b).
Discriminador.
Mezcla de varias rutas de ejecucin sin sincronizacin y ejecucin de la subsiguiente
actividad una sola vez. En [9] la descripcin del problema identicado con respecto a este
patrn con redes de alto nivel es la siguiente: El discriminador no es soportado porque
el diseador necesita mantener el nmero de hilos de ejecucin y el nmero de hilos de
ejecucin completados, adems tiene que reiniciar el constructor explcitamente a travs de
remover los tokens correspondientes a la iteracin. Con WfCCPN es posible modelarlo con
A
C
B
t
5
= Condicin: SI (t1.cont>0 & t2.cont>0 & t3.cont>0)
Accin: ENTONCES (t1.cont=t2.cont=t3.cont=t4.cont=0)
t
4
= Condicin: (t
1
.cont==0)
Discriminador
p
3
p
1
p
2
t
1
t
2
t
3
t
4
p
4
p
5
Reiniciar
D
Figura 4.8: Implementacin del patrn discriminador.
ayuda de transiciones compuestas y los contadores en las transiciones. En la gura 4.8 se
muestra de manera grca que la implementacin es similar a tener el patrn de mezcla con
sincronizacin. Se utiliza el contador de la transicin regla el cual permite saber cuantos
tokens han llegado. As, despus de que el primer token ha llegado todos los dems son
ignorados por la denicin formal de una transicin compuesta ya que cuando no cumplen
la condicin son desechados inmediatamente los tokens que llegan a sta. Adems podemos
establecer una condicin de reinicio del contador, utilizando una transicin compuesta auxiliar
que en su accin reinicia los contadores de las transiciones de las tareas involucradas, con
esto el patrn vuelve a aceptar la llegada de la primer tarea de otro conjunto de tareas.
N-salen-de-M que convergen.
Este patrn es una generalizacin del patrn anterior, pero en vez de una salida, se tienen
n salidas. Con WfCCPN es necesario modicar la condicin en la transicin regla aumentando
el valor del contador que es comparado, el cual es el contador de esa transicin.
4.5.3. Patrones estructurales
Estos patrones son fcilmente implementados con redes de Petri, debido a la nocin de
estados que dan los lugares.
A
B
C
a)Ciclos arbitrarios
b)Terminacin implcita
B
X
C end
end_s
Figura 4.9: Implementacin de los patrones de tipo estructural (basados en estados).
Ciclos arbitrarios
Ejecucin de ciclos sin restricciones estructurales. Este patrn se implementa a travs de
la estructura XOR. En determinado punto del workow es posible decidir por medio de una
condicin lgica si el ujo contina de manera normal o si es necesario regresar a una de
las tareas o eventos previos. En la gura 4.9 a) se muestra cmo a travs de las condiciones
en las transiciones regla puede ser enviado el token hacia la tarea A para que vuelva a ser
ejecutada, o que siga su ujo normal con la ejecucin de la tarea C.
Terminacin implcita
Un subproceso debe ser terminado si no tiene nada ms que hacer [33]. Con WfCCPN
se adopta una solucin similar a la de UML 2.0 presentada en [8], a travs de dos tipos de
lugares primitivos pre-etiquetados n y sub_n los cuales distinguen la nalizacin de un
subproceso y la nalizacin del proceso principal permitiendo as tener diferentes puntos de
nalizacin en el proceso de workow modelado. El caso contrario se presenta en YAWL [9],
ya que no conciben ms que un solo punto de nalizacin para un proceso workow; es por
tal motivo que no soportan este patrn.
4.5.4. Patrones de mltiples instancias
Con este grupo de patrones se manipulan mltiples ejecuciones de un sub-proceso en
el workow, es fcil para la mayora de los sistemas de workow o lenguajes de modelado
iniciar la ejecucin de mltiples instancias, sin embargo el problema se presenta al tratar con
su ejecucin, sincronizacin y terminacin.
A
B
I_a
J
K
inicio_s
I_a
Figura 4.10: Implementacin del patrn mltiples instancias sin sincronizacin.
Mltiples instancias sin sincronizacin
Este patrn considera la generacin de diferentes instancias de una actividad sin tener
sincronizacin de algn tipo entre ellas [33], este patrn se modela a travs de la siguiente
interpretacin: para tener n instancias en ejecucin es necesario colocar n tokens en un lugar
de tipo instancia.
Mltiples instancias con conocimiento a priori en tiempo de diseo
Este patrn considera generar varias instancias de un sub-proceso cuando el nmero de
esas instancias es conocido en tiempo de diseo, no es necesaria la sincronizacin entre instan-
cias [33]. Para este patrn se implementa de una forma bastante simple ya que nicamente
es necesario establecer con el peso del arco de entrada del lugar instancia el nmero n de
instancias que se desea ejecutar.
Mltiples instancias con un conocimiento a priori en tiempo de ejecucin
Con este patrn se generan varias instancias de una actividad, sin embargo aqu el nmero
de instancias a ejecutarse no se conoce al momento de disear el proceso, ya que esto se
B
inicio_s
I_a
Figura 4.11: Implementacin del patrn Mltiples instancias sin conocimiento en tiempo de
ejecucin.
decide en un punto del proceso en tiempo de ejecucin, esto es similar a tener un ciclo For
pero en paralelo [33]. Este patrn y el que se presenta en la siguiente seccin no pueden
ser implementados con CPN, de acuerdo a [9], debido a que es posible ejecutar un nmero
variable de instancias de forma paralela, sin embargo es necesario para este patrn mantener la
identidad del sub-proceso ejecutado y el nmero de instancias que se encuentren en ejecucin.
En este trabajo se utiliza un lugar especial llamado instancia el cual se propone con el n
de implementar este y el siguiente patrn. Este patrn es una generalizacin del patrn
presentado en la siguiente seccin [33], por tal razn la implementacin se presenta con el
patrn: Mltiples instancias sin conocimiento a priori en tiempo de ejecucin.
Mltiples instancias sin conocimiento en tiempo de ejecucin a priori
A
B
I
Figura 4.12: Implementacin de patrones a travs de lugares de tipo instancia
Mltiples instancias sin conocimiento a priori en tiempo de ejecucin
Con este patrn se generan varias instancias de un sub-proceso sin embargo, el nmero de
instancias no puede ser determinado, esto es similar a tener un ciclo While pero en paralelo
[33]. Por denicin un lugar instancia requiere que todas las instancias sean terminadas, una
A
B
diferido
A
B
a) Eleccin diferida utilizando arcos inhibidores
b) Eleccin diferida utilizando un lugar diferido
Figura 4.13: Implementacin del patrn: eleccin diferida.
vez que estas son nalizadas, se contina el ujo normal en el workow, de esta manera este
patrn es implementado a travs de utilizar un ciclo de modo que el lugar instancia pueda
ser alcanzado tantas veces como sea deseado sin necesidad de denir el nmero de instancias
a ejecutarse en diferentes tiempos, esta implementacin se muestra en la gura 4.11.
4.5.5. Patrones basados en estados
Estos patrones son bastante sencillos de implementar cuando la metodologa de modelado
posee la nocin de estados, tal es el caso de todo enfoque que utilice redes de Petri. En este
trabajo se mantiene la nocin de estados a travs de los lugares de la WfCCPN. Los arcos
inhibidores tambin se utilizan en la implementacin de estos patrones.
Eleccin diferida
Este patrn considera un punto en el workow en que una de varias rutas de ejecucin
es elegida, se trata de un XOR split implcito. La implementacin con WfCCPN se muestra
en la gura 4.4 c) esta permite de manera implcita elegir una tarea para su ejecucin slo
ejecutndose esa, debido al uso de arcos inhibidores los cuales mientras exista un token en
la tarea, no permitir que las dems sean activadas Otra implementacin se realiza con
lugares de tipo diferido que adems permite almacenar tokens de cualquier color, con estos
se representan eventos externos.
A
B
C
a) Enrutamiento con nter llegada en paralelo
A
J
B
b) Entregables (Milestone)
Figura 4.14: Implementacin de los patrones basados en estados
Enrutamiento paralelo con interllegada
Con este patrn se ejecutan dos o ms tareas sin importar el orden de ejecucin entre
ellas, el orden de ejecucin es determinado en tiempo de ejecucin con la restriccin de que no
puede ser ejecutadas ms de una tarea en un mismo instante, es decir no es posible ejecutarlas
en paralelo [33]. La implementacin que se propone es utilizar arcos inhibidores para lograr
la restriccin de ejecutar una tarea a la vez.
Entregables
Este patrn es muy fcil de implementar con redes de Petri, ya que nicamente se utiliza
un arco inhibidor como se muestra en la gura 4.14 b), en la gura se muestra como la tarea
J
4.5.6. Patrones de cancelacin
Los patrones de cancelacin difcilmente se encuentran soportados de manera grca por
las metodologas gracas que existen. La mayora de los sistemas de workow implementan
este patrn a travs de scripts o invocacin de comandos directamente con el workow engine
para terminar el sub-proceso o proceso principal segn sea el caso. De manera explicita con
WfCCPN se tienen lugares pre-etiquetados que representan la nalizacin y cancelacin de
B
cancel
a) Cancelacin de tareas
C fin
A
fin_s
B
cancel
b) Cancelacin de casos
C
fin
A
fin
Figura 4.15: Implementacin de los patrones de cancelacin.
procesos y sub-procesos de workow. Los lugares cancelado pueden ser alcanzados en el ujo
del proceso de manera explicita de manera implcita. Por la primera forma se entiende que
es en base a la informacin de control que es acarreada en el modelo a travs de los tokens,
que con las condiciones establecidas por ejemplo una transicin regla puede decidir cancelar
el proceso. Un ejemplo de cancelacin implcita es el incumplimiento en algn intervalo de
tiempo, vericado a travs de la estampa de tiempo del token, esto puede ser motivo para
disparar tokens hacia el lugar de cancelacin del proceso.
Cancelacin de actividades tareas
Este patrn presenta la situacin en que es necesario nalizar la ejecucin de alguna
tarea que esta ejecutndose en el proceso de workow y que no implique la nalizacin del
proceso de workow por completo [33]. En la gura 4.15 a) se muestra un ejemplo en que la
cancelacin de la tarea B no implica que se termine con la ejecucin de la tarea X y las tareas
subsiguientes. En la implementacin se deni a travs de un lugar primitivo pre-etiquetado
sub_nal, el cual consume cualquier token que llegue a ste.
Cancelacin de casos
Este patrn se reere a la cancelacin o deshabilitacin del proceso de workow [33]. Ha-
ciendo uso del lugar pre-etiquetado cancel seguido de un lugar pre-etiquetado end es posible
terminar el proceso y registrar la nalizacin del proceso como cancelacin terminacin
anormal. Como se mencion anteriormente por medio de la simulacin es posible terminar
todo el proceso con un lugar end. En la gura 4.15 b), se muestra un workow en que la
correcta ejecucin de la tarea B seguida de la tarea C, darn como resultado la nalizacin
correcta del proceso, sin embargo mediante la decisin tomada en el XOR a travs de la
transicin regla es posible cancelar la ejecucin del proceso.
4.5.7. Patrones de workow en la perspectiva de datos
En [8] se describen los patrones de workow que han sido identicados en la perspectiva
de datos en lo que respecta al modelado de workow, en este trabajo no son considerados para
la evaluacin de la metodologa propuesta debido a que es nicamente de manera parcial en
que se brindan opciones para modelar esta perspectiva, a travs de las estructuras de datos
que son representadas a travs de colores en los tokens de la WfCCPN, adems a travs de
esta investigacin se considera que estos patrones son ms apropiados para herramientas que
integran el editor de workows y el engine que permite su ejecucin.
En este captulo se mostraron las WfCCPN y los elementos que le componen y con los que
se representan los conceptos de workow en la metodologa que se propone en esta tesis. Con
stas es posible modelar la perspectiva de ujo de control sin necesidad de abstraer datos
de control como es realizado en [13]. A las CCPN originales fueron agregados elementos
extras a partir de lo estudiado en trabajos como [15], [32], [9], [10], estos elementos permiten
modelar todos los patrones de ujo de control que han sido propuestos, esto permiti evaluar
la capacidad de modelado de las WfCCPN en la perspectiva de modelado, en ese captulo
fueron mostrados los resultados obtenidos.
Captulo 5
Implementacin
En este captulo se expone la implementacin de software realizada, la cual permite utilizar
la metodologa para modelar procesos de workow propuesta en esta tesis. El sistema de
software se denomina WfECAPNSim (Workow ECA Petri Net Simulator, por sus siglas en
ingls); el captulo se encuentra dividido de la siguiente forma: la seccin 5.1 presenta los
antecedentes y una perspectiva de comparacin entre las caractersticas y modo de uso con
respecto al sistema ECAPNSim
1
, la seccin 5.2 muestra el diseo y arquitectura del sistema,
la seccin 5.3 describe las principales caractersticas que posee el sistema desarrollado, en la
seccin 5.4 se describe de forma general la forma de uso del sistema y nalmente la seccin
5.5 presenta algunos sistemas de software relacionados, adems de una breve comparacin
con respecto al WfECAPNSim.
5.1. WfECAPNSim
En [20], [19] se presenta el desarrollo del sistema ECAPNSim, el cual ofrece un medio
grco y visual para representar bases de reglas ECA a travs de las CCPN, adems permite
realizar la simulacin del comportamiento de una base de datos activa, lo que se traduce
a la simulacin de su base de reglas ECA. El modo de funcionamiento del ECAPNSim es
el siguiente: a partir de una denicin de reglas ECA especicadas en un archivo de texto
acorde a un formato predenido, el sistema construye el modelo en CCPN el cual puede ser
ejecutado a travs del juego de tokens de la CCPN. El sistema permite realizar la ejecucin de
las reglas ECA en modo simulacin, es decir nicamente se ejecuta el disparo de los tokens en
1
Sistema desarrollado en [20] con el n de utilizar las CCPN en el contexto de bases de datos activas
78 Implementacin
Transiciones temporizadas,
intervalos de tiempo.
- Caractersticas temporales
Implementada a travs de la
caracterstica de jerarqua
No necesaria Caracterstica de mltiple
instanciacin
A travs de serializacin de objetos A diferentes sistemas de bases de
datos (PostgreSQL, Oracle, Access,
MySQL).
Conexin con bases de datos
Creacin y manipulacin de
colores a travs de un editor.
Colores definidos (de acuerdo a las
sentencias SQL, i.e. color Insert,
color Delete, etc.)
Manejo de colores
Manejo de subredes mediante
lugares refinables.
- Caracterstica para modelado
jerrquico
Validacin en tiempo de diseo de
una WfCCPN bien formada
Mediante matriz de incidencia Verificacin y validacin
Juego de tokens de la WfCCPN Juego de tokens de la CCPN Simulacin
Edicin de WfCCPN No necesaria Edicin
WfECAPNsim ECAPNSim Caracterstica
Transiciones temporizadas,
intervalos de tiempo.
- Caractersticas temporales
Implementada a travs de la
caracterstica de jerarqua
No necesaria Caracterstica de mltiple
instanciacin
A travs de serializacin de objetos A diferentes sistemas de bases de
datos (PostgreSQL, Oracle, Access,
MySQL).
Conexin con bases de datos
Creacin y manipulacin de
colores a travs de un editor.
Colores definidos (de acuerdo a las
sentencias SQL, i.e. color Insert,
color Delete, etc.)
Manejo de colores
Manejo de subredes mediante
lugares refinables.
- Caracterstica para modelado
jerrquico
Validacin en tiempo de diseo de
una WfCCPN bien formada
Mediante matriz de incidencia Verificacin y validacin
Juego de tokens de la WfCCPN Juego de tokens de la CCPN Simulacin
Edicin de WfCCPN No necesaria Edicin
WfECAPNsim ECAPNSim Caracterstica
Figura 5.1: Caractersticas presentes en los dos sistemas.
la red de forma grca, en modo real a travs de la conexin a una base de datos realizando
las acciones establecidas en las reglas ECA afectando de manera real los registros de la base
de datos, adems de mostrarlo grcamente a travs de la ejecucin de la CCPN.
Para la implementacin de software realizada en esta tesis se utiliz como base de de-
sarrollo el sistema ECAPNSim. Debido a la naturaleza y modo de uso del ECAPNSim este
no posee la caracterstica de edicin de CCPN ya que no es necesaria para este trabajo, sin
embargo el WfECAPNSim no puede prescindir de dicha caracterstica, es as como este tipo
de diferencias dieron como resultado el que ciertas clases Java del sistema ECAPNSim fueran
utilizadas o modicadas, mientras que otra parte del desarrollo fue excluida. El desarrollo
del WfECAPNSim es considerado una modicacin y extensin al sistema ECAPNSim, ya
que existen algunas diferencias en cuanto a caractersticas y forma de uso, estas diferencias
se muestran en la gura 5.1.
El diseo y arquitectura del WfECAPNSim as como las caractersticas presentadas en la
tabla de la gura 5.1 se describen en las siguientes secciones.
5.2. Diseo y arquitectura
La arquitectura del WfECAPNSim se muestra en la gura 5.2. El sistema se encuentra
dividido en diferentes mdulos los cuales cumplen una funcin especca, estos mdulos se
agrupan en subsistemas los cuales se comunican e interactan entre s para proporcionar la
5.2 Diseo y arquitectura 79
funcionalidad deseada. Los componentes y sus sub-sistemas se describen a continuacin.
Editor
Simulador
Administrador
Colores
Administrador
de condiciones
Administrador
Acciones
Visualizador
Usuario
Administrador
WfCCPN
Modelos
Serializador
de objetos
Figura 5.2: Arquitectura del WfECAPNSim
5.2.1. El componente visualizador
El componente visualizador es la interfaz con el usuario, est constituido por el lienzo
(rea de dibujo rea de edicin), est permite dibujar el modelo y observar la simulacin
de la WfCCPN. Cuando una WfCCPN es creada el usuario es libre de distribuir la red de
Petri de la manera ms adecuada con el n de que al momento de ejecutar la simulacin sta
sea percibida por el modelador sin problemas. Este componente posee dos subsistemas, que
son los siguientes.
El subsistema Editor
Este subsistema controla todo lo referente a la presentacin en pantalla de la WfCCPN,
utilizando la pantalla de edicin para mostrar la construccin del modelo. Tambin propor-
ciona los controles (botones, mens, entre otros ms) necesarios para insertar cada uno de
los elementos de una WfCCPN, as tambin para modicar y establecer los valores corres-
pondientes, en este modulo se denen todos los controles y eventos de Java Swing con los
que est construida la interfaz grca del sistema.
80 Implementacin
El subsistema Simulador
Este subsistema utiliza la pantalla de edicin para mostrar la ejecucin del juego de
tokens de la WfCCPN, a travs de este mdulo se presenta la simulacin grca del proceso
de workow. La animacin se realiza a travs de los Timers que proporciona el lenguaje Java,
estos funcionan en base a la escala de tiempo congurada para la simulacin.
5.2.2. El componente administrador de modelos
Este componente se encarga de mantener la relacin lgica entre cada uno de los elementos
que componen el modelo, tales como: lugares, transiciones, arcos, sub redes, conjunto de
colores y los elementos que dan el enfoque de regla ECA, es decir el conjunto de Acciones y
las Condiciones, adems se mantiene un registro histrico de las ejecuciones, todo lo anterior
se realiza para cada proceso de workow modelado de manera independiente. A continuacin
se describen los subsistemas de este componente.
Administrador de WfCCPN
Este subsistema permite en tiempo de diseo administrar el control del grafo formado
por los elementos de la WfCCPN manteniendo la relacin entre ndices de cada uno de estos
elementos, por ejemplo la relacin que existe entre una transicin y sus diferentes arcos de
entrada; en base a ndices permite que en caso de ser eliminado algn elemento sea invocado
un mtodo, el cual mantiene la consistencia en la relacin y estructura de la red de Petri, de
esta manera al establecer alguna relacin invlida entre elementos, el subsistema se encarga
de anular la accin del usuario y enviar el mensaje correspondiente.
Administrador de colores
Este componente permite la gestin de tipos de datos (colores) para el proceso a modelar,
la estructura de un color es similar a una estructura de datos propia del lenguaje C, a partir
de la creacin de un color, se denen sus atributos, los cuales son de un tipo de dato ya
sea numrico o de tipo texto, incluso otro color, es decir colores formados por otros colores.
Adems es posible asociar un color RGB del sistema operativo a cada denicin, esto para
efectos de diferenciar visualmente los colores de tokens al momento de ejecutar la simulacin.
5.2 Diseo y arquitectura 81
Administrador de condiciones
Este subsistema permite la denicin de condiciones lgicas y temporales en las tran-
siciones, su evaluacin se realiza a travs de un analizador y evaluador de condiciones, el
cual transforma la expresin a su forma postja para ser evaluada, adems en caso de que
la condicin haga referencia hacia atributos de color del token evaluado se obtiene el valor,
cabe recordar que un token puede contener como atributo otro color que a su vez contendr
atributos, de este modo, el sistema tiene la capacidad de encontrar el atributo nal al que
se hace referencia en la condicin. Por otro lado las condiciones temporales son de dos tipos:
condicin de cumplimiento de un plazo y condicin de un intervalo vlido para el disparo
de transiciones, de estas condiciones posteriormente se presenta una explicacin de como se
utilizan en el sistema.
Administrador de acciones
Este subsistema permite la denicin de acciones, para esta primera versin del software
WfECAPNSim se implemento una interfaz tipo asistente de aplicaciones el cual permite
denir 5 tipos bsicos de acciones, esta interfaz tiene por objetivo mantener la consistencia
en las acciones denidas con respecto a los elementos de la WfCCPN que posea en el momento
de la denicin. Por ejemplo, cuando un lugar es eliminado, la consistencia es vericada por
este subsistema, alertando de los cambios y posibles errores que se pueden desencadenar
debido a la eliminacin de ese elemento.
5.2.3. Serializador de objetos
Cuando el usuario modela un proceso de workow, necesitar almacenarlo y recuperarlo
para posteriores sesiones de trabajo, este requerimiento bsico en la mayora de los sistemas
de software, se provee en WfCCPN a travs de la serializacin de objetos proporcionada por
el lenguaje Java, con esto se logra no tener dependencia de algn mtodo de almacenamiento
externo como pudiese ser una base de datos relacional. La serializacin es un mtodo que
permite mantener los objetos construidos con Java, guardando su estructura y valores ac-
tuales, de esta manera es posible guardar la red generada con todos sus elementos (lugares,
transiciones, arcos, tokens, pginas de instancias y jerarqua, conjunto de colores, adems de
las condiciones y acciones asociadas a las transiciones del modelo). De esta manera cuando
se guarda un modelo se guarda toda la informacin asociada a este.
82 Implementacin
En el sitio web http://www.wfccpn.org es posible obtener informacin ms detallada en
cuanto al diseo e implementacin (cdigo fuente) del sistema WfECAPNSim. En la siguiente
seccin se muestra la implementacin de los componentes anteriormente descritos y la forma
en que se presentan al usuario a travs de las interfaces del sistema.
5.3. Caractersticas
WfECAPNSim permite utilizar la metodologa propuesta para modelar procesos de work-
ow a travs de WfCCPN aadiendo caractersticas de workow. La descripcin de cada una
de estas caractersticas se realiza en algunos casos mostrando las pantallas correspondientes
del sistema. En la gura 5.3 se presenta la pantalla principal del sistema.
Grupo de botones para
insertar y editar elementos de
una WfCCPN
Reloj y control de
velocidad de la simulacin
Botones para
controlar la
simulacin
Botones para administrar el
modelo generado
Barra de mens del
WfECAPNSim
Figura 5.3: Pantalla principal del WfECAPNSim
5.3 Caractersticas 83
5.3.1. Edicin de WfCCPN
Esta es la primera caracterstica con la que el usuario del sistema interacta, la edicin
proporciona facilidades para un rpido diseo a travs de controles y eventos necesarios. Se
diseo de tal modo que los elementos de la pantalla principal sean sucientes para crear una
WfCCPN de manera intuitiva. En la gura 5.3 se muestran las diferentes barras de botones y
controles que posee el sistema. A continuacin se muestran los detalles de edicin para cada
uno de los elementos de una WfCCPN.
Lugares
Cada tipo de lugar de una WfCCPN puede ser insertado con su respectivo botn que
se encuentra en la barra de botones de la izquierda. Una vez insertado un lugar, es posible
asignarle un color de dominio, asignarle tokens, establecer informacin descriptiva, adems
de tener la opcin de eliminarlo desplazarlo dentro del lienzo.
Figura 5.4: Edicin de lugares
En la gura 5.4 se muestra el men contextual y las opciones que corresponden a un lugar
de tipo primitivo. Cuando se conoce el color de los tokens que llegaran a un determinado
lugar o se desea restringir el color de los tokens que pueden llegaran al lugar, se utiliza el
dominio de color, el dominio se establece con la asociacin de uno de los colores denidos a
travs del editor de colores.
84 Implementacin
En cuanto a la asignacin de tokens en los lugares virtuales se tiene la posibilidad de
asignar tokens negros (neutros) y tokens de cualquier color (datos) . En los lugares primitivos
nicamente es posible introducir tokens de color de su dominio, es preciso mencionar, que
en caso de cambiar el color de domino cuando este ya hubiese sido establecido, entonces los
tokens existentes (dentro de ese lugar) en ese momento son eliminados. En los restantes tipos
de lugares no esta presente la opcin de insertar tokens mediante edicin del usuario.
La informacin descriptiva en los lugares consiste en especicar si el lugar representa
cualquiera de las siguientes situaciones: evento de una regla, accin de una regla, evento de
una regla y accin de otra, accin de una regla y evento de otra, la interfaz se muestra en la
gura 5.5 b) y es acorde a la metodologa sugerida en el capitulo 4, tambin se tiene un rea
de texto para introducir de manera libre la descripcin de lo que representa ese lugar.
Figura 5.5: Edicin de informacin adicional en los lugares
Transiciones
Una transicin de tipo copia no contempla datos adicionales para edicin tal y como se
muestra en la gura 5.6 b), sin embargo las transiciones de tipo regla y compuesta permiten
la denicin de una condicin y una accin, la forma de denir una condicin y una accin,
las guras 5.6 c) y 5.6 a) se muestran los mens contextuales para estas transiciones respec-
tivamente, por ltimo las transiciones tiempo permiten dos comportamientos diferentes, ya
sea como transicin temporizada o con intervalos de tiempo vlidos para su activacin, en la
gura 5.6 d) se muestra la opcin dentro del men que despliega la interfaz para especicar
alguno de los comportamientos citados.
a) b)
c) d)
Figura 5.6: Edicin de transiciones de una WfCCPN
Para intervalos de tiempo el usuario tiene la posibilidad de establecer el intervalo mnimo
de activacin sin establecer la fecha y la hora, con esto se indica que el intervalo mnimo
puede ser cualquiera menor al intervalo mximo. Tambin es posible especicar la fecha y
la hora, o nicamente la fecha, o de igual manera nicamente establecer la hora; las mismas
opciones se tienen para el intervalo mximo. Sin embargo es necesario que en el caso de las
tres ultimas formas, estas se correspondan entre el intervalo mnimo y el mximo. La interfaz
se muestra gura 5.7.
Para incluir retardos (delays) en el disparo de la transicin tiempo se realiza con el se-
gundo conjunto de opciones mostrado en la g. 5.7. Es posible establecer retardos constantes
en unidades de tiempo, recordando que la unidad de tiempo especicada en milisegundos en
funcin de la conguracin para la simulacin que ser mostrada en la seccin 5.3.6. Tambin
86 Implementacin
Figura 5.7: Transiciones tiempo
es posible establecer valores aleatorios con distribuciones discretas de probabilidad. Los val-
ores generados estn en el rango de 0 a 1, por lo que el usuario tiene la opcin de establecer
un factor de multiplicacin y un intervalo de nmeros aleatorios aceptados.
5.3.2. Editor de colores
La denicin de los colores, (es decir los tipos de datos) realiza a travs del editor de
colores, siendo posible guardar y reutilizar el conjunto de colores en otros modelos. Los pasos
para denir un conjunto de colores son los siguientes: Primero se dene el nombre del color,
utilizando el botn agregar, el color es guardado y de esta manera es posible agregar los
atributos deseados que pueden ser de los siguientes tipos: Char, Varchar, Integer, Float,
Numeric, Date, Time, Timestamp, Color.
Adems es posible asignarle un color del sistema para representarlo de manera grca.
En la gura se muestra el editor de colores.
5.3.3. Condiciones
Las condiciones lgicas se asignan a transiciones tipo regla y compuestas, mientras que
las condiciones temporales nicamente se asignan a transiciones compuestas.
Figura 5.8: Administrador de colores del WfECAPNSim
88 Implementacin
Lgicas
La manera de asignar una condicin lgica es a travs de una cadena de texto denida a
travs de operadores lgicos. Los operadores utilizados son los siguientes:
Operadores de comparacin: <, >, <=, >=, =, <>
Operadores de asociatividad: |, &, (, )
Temporales
Las condiciones temporales se asignan a transiciones compuestas, estas condiciones pueden
comparar la fecha y hora del reloj de la simulacin contra la estampa de tiempo de creacin
o de modicacin en los tokens al momento de llegar a una transicin compuesta.
5.3.4. Acciones
Si la condicin establecida en la transicin al ser evaluada resulta verdadera, entonces
opcionalmente una accin puede ejecutarse, logrando de esta manera representar completa-
mente el comportamiento de una regla ECA, para este trabajo se plantearon cinco acciones
bsicas, la denicin de la accin se realiza a travs de un editor de denicin el cul lleva
paso a paso al usuario en la creacin y conguracin de la accin, reduciendo de esta manera
la posibilidad de introducir errores en su denicin. A continuacin se describen las posibles
acciones que pueden adjuntarse a una transicin de tipo regla compuesta.
Modicar atributos en el color del token
Con esta accin es posible modicar el valor de cualquiera de los atributos del color
referenciado en los tokens que son evaluados dentro de la transicin que posee la accin
asignada. Al establecer los atributos que se desean modicar es posible incluir operadores
bsicos para los atributos numricos, valores constantes como cadenas de texto. El sistema
mantiene la consistencia en el modelo a travs de vericar que el dato asignado al atributo
corresponda con su tipo denido en el color. En la gura 5.9 se muestra cmo el atributo
revisado del color documento ser modicado al asignrsele el valor de tipo texto: revisado,
al cumplirse la condicin y ejecutarse la accin en la transicin compuesta.
Figura 5.9: Editor de acciones - Modicacin de atributos en colores de tokens
Crear tokens con un color nuevo
Este tipo de accin permite obtener tokens con colores compuestos a travs de la creacin
de nuevos colores en donde los atributos del nuevo color se toman de los colores de tokens
que llegan desde los lugares de entrada de la transicin que posee la accin. En tiempo de
edicin es conveniente denir los colores de los lugares de entrada de la transicin asociada
con la accin, ya que a partir de esos colores quedar denido el espacio de colores del cual
ser posible crear el nuevo color, cabe mencionar el caso en que uno de los lugares de entrada
de la transicin es de tipo virtual, entonces el espacio de colores ser el conjunto total de
colores del modelo.
Al crear el token con el color nuevo, ser posible establecer los valores deseados en
cualquiera de los atributos, sin embargo se tiene la posibilidad de asignar los valores que
contienen los tokens formadores del token nuevo, esto se obtiene a travs de mantener en
blanco la celda correspondiente a la columna valor (value) de los atributos deseados.
Seleccionar tokens
Esta accin permite establecer los tokens en base a su color, a los cuales se les permite
pasar hacia el lugar de salida, los que no se especiquen sern eliminados.
90 Implementacin
Figura 5.10: Administrador de acciones - Creacin de colores para tokens
Eliminar tokens
Con esta accin es posible modelar situaciones de cancelacin en un workow, si la condi-
cin establecida en la transicin se cumple, entonces los tokens existentes en los lugares
seleccionados a travs del asistente de acciones, sern eliminados.
Modicacin del contador en las transiciones
Es posible manipular el valor del contador que poseen las transiciones, si una condicin
se cumple el contador puede ser reiniciado a 0, o puede ser inicializado al valor establecido a
travs del editor de acciones.
5.3.5. Jerarqua y mltiples instancias
Mediante la denicin de sub-pginas es posible denir una sub-red. Una sub-pgina de
un lugar de tipo sub_red o instancia, posee un lugar virtual para el inicio del sub-proceso y
un lugar primitivo para su nalizacin de ese sub-proceso. El sistema permite la edicin de
una sola pgina a la vez, en caso de tener abiertas otras sub-pginas stas sern desactivadas
para su edicin y el sistema las presenta en modo de inspeccin. En la gura 5.11 se muestra
Figura 5.11: Administracin de sub-pginas
la denicin de dos sub-pginas, los controles de edicin son los mismos que los de la pantalla
principal del WfECAPNSim.
Es posible establecer el comportamiento en tiempo de ejecucin para las sub-pginas de
jerarqua y de instancia, a travs de congurar el sistema para que la ejecucin de todas las
sub-pginas sean no, visualizadas; tambin es posible congurar el sistema de modo que
este pregunte por cada sub-pgina si desea o no visualizar la ejecucin.
5.3.6. Simulacin
La simulacin se realiza por medio del juego de tokens de la red WfCCPN, mediante
temporizadores controlados por tiempos. El sistema permite iniciar, detener o pausar la
simulacin, de esta manera es posible observar los detalles y la informacin que va cambiando
con el tiempo, para observar la informacin de un lugar basta con colocar el puntero del ratn
sobre ste e inmediatamente se muestra dicha informacin a travs de un tool tip text; a
92 Implementacin
travs de la conguracin general del sistema es posible denir la informacin que se desea
visualizar, siendo posible conocer la informacin de los atributos del color en los tokens que
se encuentren en ese momento dentro del lugar.
Figura 5.12: Conguracin del tiempo para la ejecucin de simulaciones.
Tiempo
El sistema permite modelar procesos de workow que tienen en cuenta el tiempo en que
se realizan ciertas tareas, para esto se proporciona la posibilidad de tener unidades de tiempo
escaladas en milisegundos, as como tambin es posible denir la fecha y hora de inicio de la
simulacin, en la gura 5.12 se muestra el panel de conguracin.
Es posible que las unidades de tiempo sean segundos, minutos, horas, das o meses, por
defecto el sistema est congurado para trabajar con un segundo como unidad de tiempo el
cual se encuentra congurado para que su escala sea 1000 milisegundos, es decir, el tiempo
real de un segundo. En la segunda seccin de conguracin es posible denir tres valores:
Reloj del sistema, con esta opcin la simulacin se inicia con la fecha y hora actual del sistema
operativo; Cronmetro con esta opcin nicamente se visualizan las horas con sus minutos
y segundos, iniciando desde cero; y por ltimo es posible personalizar la fecha y hora que se
5.4 Modo de uso 93
desea aparezca como inicio de simulacin. Es en base a esta conguracin de tiempo que son
evaluadas las condiciones temporales en las transiciones de tipo tiempo y compuestas.
Reportes
Los reportes que proporciona el sistema son referentes a la interpretacin dada de la red
WfCCPN con relacin al proceso de workow modelado. Es posible congurar la informacin
que se desea mostrar en los reportes, esta puede ser la siguiente: mostrar detalle de los eventos,
condiciones y acciones ejecutadas, lo cual adems contempla mostrar la fecha y hora en que
ocurren es decir, el momento en que un token llega a un lugar o a una transicin. tambin
se pueden mostrar los resultados de las evaluaciones en las condiciones, otra informacin que
puede mostrarse en los reportes se reere a los tokens eliminados por no cumplirse alguna
condicin.
Validacin de modelos
La validacin del proceso de workow se realiza en tiempo de diseo y nicamente com-
prueba que la red WfCCPN sea construida de forma vlida, de esta manera se validan las
conexiones entre elementos de la WfCCPN, por ejemplo un lugar de tipo virtual no puede
tener una transicin de entrada tipo regla, cuando el sistema detecta esta situacin, enva un
mensaje e ignora la edicin del usuario.
5.4. Modo de uso
El sistema WfECAPNSim, puede utilizarse de la manera a la que ms se adapte el usuario,
sin embargo se consider la presente seccin para ilustrar de manera general como el usuario
que modela procesos de workow, puede realizar esta tarea utilizando el sistema presentado
en este captulo.
En la gura 5.13 a travs de UML con un diagrama de secuencia se muestra un caso
general de cmo el usuario construye el modelo de un proceso de workow. A travs del
men archivo la interfaz de usuario puede crearse un nuevo modelo y guardarse como un
nombre de archivo y la extensin .cpn, una vez que el usuario ha creado el nuevo proyecto,
es aconsejable crear el conjunto de colores identicado para el proceso de workow, esto es
la denicin de los tipos de datos a travs del administrador de colores. Con el conjunto
94 Implementacin
Figura 5.13: Diagrama de secuencia para describir el modo de uso del sistema WfECAPNSim
de colores creado es posible iniciar la construccin de la red WfCCPN representando las
reglas ECA identicadas en el proceso de workow, estableciendo la informacin relevante
en cada elemento de la WfCCPN, al tener el grafo dibujado el cual se encuentra formado
por los elementos WfCCPN, es posible denir las condiciones y las acciones que se adjuntan
a las transiciones de tipo regla y compuestas, as como los detalles temporales a travs de
las transiciones tiempo. Una vez que se tiene el proceso modelado con todos sus detalles y
datos asignados a los elementos WfCCPN, es posible congurar el tiempo y su escala para
la ejecucin de la simulacin. Para posteriormente tener la posibilidad de ejecutar, pausar o
detener la simulacin. El registro de cada simulacin puede obtenerse a travs de los registros
histricos que proporciona el sistema. De esta manera el modelador de procesos de workow
puede repetir el ciclo de diseo y modelacin tantas veces sea considerado necesario, hasta
obtener la mejor representacin del proceso modelado en WfCCPN a juicio del usuario.
5.5. Sistemas de software relacionados
En captulos anteriores han sido mencionados diversos sistemas administradores de work-
ow, algunos poseen licencias comerciales y otros ms licencia libre
2
, de estos sistemas una
parte nicamente contempla la denicin de procesos de workow para su simulacin y anli-
sis, mientras que otros adems contemplan la representacin de las deniciones a travs de
un motor de workow para su ejecucin y monitoreo real del proceso, es decir son sistemas
administradores de workow completos. La gran cantidad de sistemas adems de la diversi-
dad en cuanto a tecnologas utilizadas y metodologas empleadas para modelar los procesos
de workow, convierte en prcticamente imposible la tarea de realizar una comparacin com-
2
En [34], [35], [17] es posible encontrar referencia a sistemas desarrollados en lenguaje Java, que son de
licencia libre.
5.5 Sistemas de software relacionados 95
pleta y objetiva con cada uno de los sistemas existentes, por lo tanto de todas las opciones se
eligieron tres sistemas los cuales permiten obtener un punto de comparacin ms justo con
respecto al sistema WfECAPNSim.
Los sistemas COSA, YAWL, WoPeD, BOSSA, XRL/Lower, Renew, ExSpect y Flower
son sistemas basados en redes de Petri y al igual que el WfECAPNSim son implementaciones
realizadas con tecnologa Java. Sin embargo la lista se reduce debido a que los sistemas
COSA, ExSpect y Flower poseen licencia comercial, de estos tres slo fue posible obtener
una versin demo de ExSpect. Por otro lado XRL/Lower es un sistema basado en web, el
cual su denicin se basa en Workow Nets, sin embargo no contempla la denicin grca
de los procesos de workow, debido a que los procesos de denen a travs de XML utilizando
XRL (eXchangeable Routing Language), al no ser una herramienta grca, no se consider
para los objetivos de comparacin.
Si No No Si Mltiples instancias
WfCCPN bien formada No No Si Validaciones
Si Si No Si Reportes
Si No No Si Jerarqua
Si No No Si, a travs de un
modulo adicional
Caractersticas de
tiempo
Si No Si, pero es
manual
Si Juego de tokens
Definicin de Colores Definicin de
datos
No A travs de
definiciones XML
Perspectiva de datos
Si No Si Si Patrones de
workflow
No Si No Si Motor workflow
Redes de Petri de alto
nivel (WfCCPN)
Redes de Petri
bsicas
Wf-Nets Lenguaje basado en
Wf-Nets
Tipo de red de Petri
que utiliza
WfECAPNSim Bossa WoPeD YAWL Caracterstica
Si No No Si Mltiples instancias
WfCCPN bien formada No No Si Validaciones
Si Si No Si Reportes
Si No No Si Jerarqua
Si No No Si, a travs de un
modulo adicional
Caractersticas de
tiempo
Si No Si, pero es
manual
Si Juego de tokens
Definicin de Colores Definicin de
datos
No A travs de
definiciones XML
Perspectiva de datos
Si No Si Si Patrones de
workflow
No Si No Si Motor workflow
Redes de Petri de alto
nivel (WfCCPN)
Redes de Petri
bsicas
Wf-Nets Lenguaje basado en
Wf-Nets
Tipo de red de Petri
que utiliza
WfECAPNSim Bossa WoPeD YAWL Caracterstica
Figura 5.14: Comparativa entre sistemas de software relacionados
En la tabla de la gura 5.14 se muestran las caractersticas principales que poseen los
sistemas comparados, los que a pesar de que tienen ms tiempo y ms recursos humanos en
su desarrollo pueden comprarse con el WfECAPNSim. El sistema YAWL [9] es resultado de
ms de 10 aos de trabajos de investigacin por parte del doctor Wil Van der Aalst y su
96 Implementacin
equipo de colaboradores, este sistema hace uso de un lenguaje basado en las Wf-Nets que
son un tipo de red de Petri, este sistema implementa todas las caractersticas tomadas en
cuenta para la comparacin realizada, el nico detalle que puede ser mencionados sobre este
sistema es sobre la denicin de datos ya que se realiza de forma manual a travs XML, sin
embargo este es el software ms importante actualmente y del cul otros desarrollos toman
ideas y conceptos, tal como fue hecho en este trabajo de tesis. Existen sistemas de software
que hacen uso de las Wf-Nets para la denicin de los proceso de workow y el motor de
YAWL a travs de una interfaz, para la ejecucin de los procesos, tal es el caso de WoPeD [36]
el cual se considera como punto de referencia ms justo con el sistema WfECAPNSim debido
a que son herramientas para la denicin de procesos y no motores de workow, y como se
muestra en la tabla comparativa son varias las ventajas de nuestro sistema sobre WoPeD. En
el caso de Bossa [37] su mayor desventaja es la falta de apego al modelo de referencia de la
WfMC, adems de no existir alguna evaluacin utilizando los patrones de workow, si bien
utilizan redes de Petri, no utilizan la caracterstica de colores en estas.
La implementacin de software desarrollada tiene su contribucin como herramienta de
modelado y simulacin de procesos de workow a travs de redes de Petri; el cdigo fuente
del WfECAPNSim se distribuye bajo licencia GPL y se encuentra disponible para su uso o
modicacin de manera libre en la direccin de Internet: http://www.wfccpn.org. El sistema
desarrollado ofrece caractersticas de redes de Petri las cuales por lo general nicamente se
ofrecen en sistemas de software comerciales, es decir es necesario pagar cierta cantidad de
dinero para poseer el programa de software, algunas de estas caractersticas son el manejo
de colores, el diseo de modelos jerrquicos, y caractersticas temporales. Es bastante amplio
el tema de workow, por lo tanto las caractersticas que ofrece el WfECAPNSim pueden
seguir desarrollndose, sin embargo se considera una buena aproximacin como herramienta
de modelado grco y de simulacin para procesos de workow, la cual se considera como
una base slida para explorar la construccin de un motor de workow el cul permita la
ejecucin de los procesos modelados.
Captulo 6
Metodologa y un caso de estudio
En el captulo anterior se present la implementacin de software realizada con el n de
utilizar las WfCCPN para modelado de procesos de workow. En este captulo se muestra
la metodologa propuesta en este trabajo de tesis, adems a travs de un ejemplo se describe
la manera de modelar procesos de workow a travs de utilizar las WfCCPN y el sistema
WfECAPNSim.
6.1. Metodologa propuesta
La metodologa para modelar procesos de workow que se propone con este trabajo de
tesis consiste en lo siguientes pasos.
1. Identicar las tareas y dems conceptos que contiene el proceso de workow que se
modelar.
2. Identicar las reglas ECA que componen al proceso de workow.
3. Identicar los datos que tienen relevancia dentro del proceso de workow.
4. Representar al proceso de workowa travs de reglas ECAmediante la sintaxis sugerida.
5. Generar la WfCCPN en base a las reglas ECA resultantes, utilizando el sistema WfE-
CAPNSim.
6. Generar el conjunto de colores (datos) identicados en el paso 2.
98
7. Congurar la WfCCPN para su ejecucin, aadiendo datos descriptivos y datos tem-
porales en los elementos de la WfCCPN.
8. Guardar el archivo resultante y realizar las simulaciones del proceso modelado.
9. Ajustar el modelo, hasta obtener el comportamiento y resultados deseados.
6.1.1. Identicar el proceso de workow
En la seccin 4.4 se describen los elementos que componen a un proceso de workow, y
la manera en como se representan a travs de los elementos de una WfCCPN. Mientras que,
en la seccin 4.3.4 se muestra la manera general de representar los elementos de una regla
ECA a travs de una WfCCPN. Al haber realizado los paso 1, 2 y 3 es posible representar al
proceso a travs de reglas ECA, las cuales sern descritas mediante la siguiente sintaxis.
6.1.2. Representacin del proceso a travs de reglas ECA
La representacin del proceso a travs de reglas ECA se reere al paso 4 de la metodologa.
La sintaxis
1
para describir los elementos del workow como reglas ECA se deriva de la
utilizada en [20].
Eventos. Un evento se dene utilizando la palabra ON, seguido del nombre del evento, sin
embargo cuando se trata de un evento compuesto se utiliza la palabra que describa el tipo de
evento, que pueden ser las siguientes: AND_SPLIT, AND_JOIN, OR_SPLIT, OR_JOIN,
XOR_SPLIT. Estas representan las construcciones bsicas de enrutamiento en un proceso de
workow. Adems, los eventos compuestos denidos en [20] pueden ser implementados, estos
son los siguientes: SEC (secuencia), SIM (simultneo), TIMES (historia), NOT (negacin),
CLOSURE (cerradura), ANY (cualquiera).
Sintaxis: ON ( tipo_evento (evento
1
:evento
2
: ... :evento
n
) | regla_eca )
Condiciones. Las condiciones se establecen comparando los tipos de datos primitivos
permitidos y los colores denidos por el usuario, incluyendo los de tipo fecha.
Sintaxis: IF ( true | false | condicin )
1
Se utiliza el idioma ingls para la descripcin, con el n de mantener relacin con los trabajos anteriores
sobre CCPNs.
6.1 Metodologa propuesta 99
Acciones. Para las acciones se deni un conjunto bsico. stas son las siguientes: AC-
TION_CREATE (permite crear colores compuestos en los tokens), ACTION_MODIFY
(permite modicar atributos en los colores de los tokens), ACTION_PASS (permite dis-
crimar colores), ACTION_DELETE (permite eliminar tokens), ACTION_TCOUNT (per-
miten modicar el valor del contador de una transicin).
Sintaxis: THEN ( tipo_accion
1
.. tipo_accion
n
| regla_eca )
Intervalos de Tiempo. Para este trabajo se utiliza la dimensin de intervalos de tiempo
vlidos para las reglas ECA, con lo que es posible agregar una condicin extra, la cual
verica que la ejecucin de la regla ECA sea dentro de los intervalos de tiempo inicial y nal
especicados en esta parte de la regla.
Sintaxis: VALID TIME ( intervalo
inicial
- intervalo
final
)
Representacin de un conjunto de reglas ECA
Las siguientes reglas ECA se representan con WfCCPN en la gura 6.1.
Regla_1
ON ( evento
1
)
IF ( evento1.fecha
creacion
< fechaPlazo
1
)
THEN Regla_2
Regla_2
ON OR_SPLIT( evento
2
: evento
3
: evento
4
)
IF TRUE
THEN Regla_3
Regla_3
ON OR_JOIN( evento
2
: evento
3
: evento
4
)
IF TRUE
THEN Regla_4
Regla_4
ON( evento
5
)
IF (evento
2
.variable = aprobadoj | evento
3
.variable = aprobadoj | evento
4
.variable =
aprobadoj )
100
Accin
CrearToken
Evento
1
Evento
4
Evento
3
Evento
2
Evento
5
Condicin temporal
Condicin
Regla_1
Regla_2
Regla_3
Regla_4
Figura 6.1: Representacin de un conjunto de reglas ECA a travs de WfCCPN.
6.2 Seleccin de artculos para un congreso cientco 101
THEN CREATE_TOKEN( token_final )
En la gura 6.1 se muestra un conjunto de cuatro reglas ECA y la forma en cmo stas
se relacionan al modelarlas con WfCCPN.
Una vez que se han identicado y representado las reglas ECA a travs de la sintxis
sugerida, es posible realizar los pasos posteriores de la metodologa.
6.1.3. Generacin de la WfCCPN y uso del WfECAPNSim
Los pasos 5, 6, 7 y 8 consisten en generar (dibujar) la WfCCPN y ejecutar simulaciones
de sta a travs del sistema WfECAPNSim, en el captulo 5 se muestra de manera detallada
la forma de uso del sistema, explicando la manera en como generar cada uno de los elementos
que componen a una WfCCPN.
Actualmente, el sistema WfECAPNSim carece de implementaciones de software que per-
mitan validar y vericar los modelos obtenidos.
A continuacin se presenta un ejemplo, con el n de mostrar de manera especica el uso
de la metodologa.
6.2. Seleccin de artculos para un congreso cientco
La organizacin de un congreso cientco presenta un reto en cuanto a organizacin se
reere, son diversas las tareas que deben ser llevadas a cabo para su realizacin exitosa, de
manera general es posible identicar los procesos principales que ataen a la organizacin de
un evento de este tipo, a continuacin se menciona una posible lista de los procesos realizados
antes de la fecha del evento:
Proceso de publicidad y difusin del evento.
Proceso referente al aseguramiento de instalaciones y la logstica.
Proceso de seleccin de artculos, posters, talleres propuestos por los participantes al
evento.
102
Proceso de elaboracin y realizacin del programa nal del congreso.
Para este ejemplo se toma el tercer proceso para ser modelado a travs de WfCCPN,
se contempla nicamente el caso de seleccin de artculos sometidos para publicacin en el
congreso. A continuacin se describe el proceso de workow correspondiente.
6.2.1. Descripcin del workow
El proceso se inicia con la convocatoria call for papers dirigida a la comunidad cientca
relacionada con la temtica del congreso, con el n de que enven en forma de publicacin
los resultados de sus investigaciones, en la convocatoria se estipula el formato para escribir
el artculo, la fecha lmite para el envi de de los artculos, la fecha para la noticacin sobre
aceptacin o rechazo del articulo, fecha limite para envo de la versin nal para publicacin
en caso de haber sido aceptado. Tambin se estipula el procedimiento de envo del articulo, en
ocasiones se realiza nicamente envindolo va correo electrnico, sin embargo generalmente
es necesario enviar un formulario con datos necesarios para una mejor administracin del
proceso de recepcin de artculos por parte de los organizadores.
Para este ejemplo se contempla el envo del registro y envo del articulo para completar
el proceso de someter el articulo en su primera versin por parte del autor. La fecha lmite
para el envo de artculos decide si es aceptado o no el artculo para ser evaluado. Una vez
llegada a esa fecha, el proceso recae en los organizadores del congreso, y se inicia la gestin
para evaluar los trabajos recibidos con el n de seleccionar los trabajos que cumplan con
ciertos requisitos de calidad deseados por el comit de organizadores. Comnmente se tiene
un comit de revisores formado por personalidades con trayectorias sobresalientes dentro de
la temtica del congreso, de modo que expertos en los temas de los trabajos recibidos tienen la
tarea de evaluarlos. Generalmente cada uno de los trabajos es enviado a tres revisores para su
evaluacin con el n de que realicen los comentarios pertinentes y den su veredicto sobre si el
trabajo debe ser aceptado, aceptado condicionalmente (siempre y cuando el autor realice las
modicaciones sugeridas por los revisores) o rechazado. Este proceso de evaluacin tiene una
duracin lmite al estipulado como fecha de noticacin de resultados a los autores. Por esta
razn una vez que los tres revisores entregan sus evaluaciones, el comit organizador tiene la
decisin de aceptar y rechazar artculos, en los siguientes casos el articulo es aceptado:
al menos dos evaluaciones con resultado aceptado
al menos una evaluacin con resultado aceptado y una con resultado aceptado condi-
cionalmente
al menos se tienen dos resultados de aceptado condicionalmente.
Basta tener dos resultados de rechazo, para que el artculo sea descartado para su publi-
cacin en el congreso. A travs de la informacin de contacto que se recibi en el formulario
de registro, se enva la noticacin a los autores, as como las observaciones realizadas por
los revisores. Una vez que los autores a los cuales su artculo fue aceptado, tienen la tarea de
enviar una versin nal al comit organizador. Esta tarea da n a este proceso de workow.
6.2.2. Modelo del proceso de workow
A continuacin se presenta el modelo que se obtuvo a partir de la descripcin del proceso
genrico de seleccin de artculos para su publicacin en congresos cientcos, primero a partir
de la descripcin se identican las reglas ECA, expresndolas a travs de la sintaxis sugerida
en el capitulo 4; una vez que se tienen las reglas se crea el conjunto de colores, es decir todos
los datos que participan en el proceso de workow, de esta manera es posible generar las
estructuras de WfCCPN que permitan representar tanto las reglas ECA como los datos del
proceso de workow a travs del sistema WfECAPNSim.
6.2.3. Conjunto de Reglas ECA
El conjunto de reglas ECA identicadas en el workow descrito anteriormente se lista a
continuacin.
Regla_1
ON Inicio
IF TRUE
THEN Regla_2
Regla_2
ON AND_SPLIT(EnvioRegistro : EnvioArticulo)
IF
c1.timestampCreate < fechaLimite AND
104
c2.timestampCreate < fechaLimite
THEN
ACTION_CREATE(ArticuloRegistrado)
Regla_3
ON Recepcin
IF TRUE
THEN AND_SPLIT(Regla_4 : Regla_5 : Regla6)
Regla_4
ON Revisor1
IF t.delay=true
THEN Regla_7
Regla_5
ON Revisor2
IF t.delay=true
THEN Regla_8
Regla_6
ON Revisor3
IF t.delay=true
THEN Regla_9
Regla_7
ON Evaluacion1
IF true
THEN ACTION_CREATE(calicacion1)
Regla_8
ON Evaluacion2
IF true
Regla_9
ON Evaluacion3
IF true
Regla_10
ON
AND_JOIN(calicacion1 : Calicacion2 : Calicacion3)
IF
calicacion.desicion=aceptado
THEN
ACTION_COUNT(incremento)
ACTION_CREATE(Noticacion)
Regla_11
ON Noticacion
IF if ( contador.Transicin.Regla_10 >= 2)
THEN Regla_12
Regla_12
ON OR_SPLIT (SUB_NET(Aceptado) : SUB_NET(Rechazado))
IF -
THEN -
Regla_13
ON SUBNET(Aceptado)
IF TRUE
THEN CANCEL
Regla_14
ON AND(Noticacion:Preparacion camera ready)
IF Articulo.timestamp_Create < Plazo_CameraReady
THEN Enviar Articulo al editor del congreso
Regla_15
ON Articulo nal enviado al editor del congreso
IF TRUE
THEN END
Regla_13
106
ON SUBNET(Rechazado)
IF TRUE
THEN CANCEL
6.2.4. Conjunto de colores
Los datos necesarios para modelar el proceso se muestran en la gura 6.2 a travs del
conjunto
P
de colores denidos para este proceso de workow.
C
1
: Registro
Autor de contacto (String)
Institucin (String)
correo-e (String)
C
2
: Articulo
Nombre archivo (String)
C
3
: Calificacin
Comentario (Text)
Desicin (String)
C5 (ArticuloRegistrado)
C
4
: Notificacin
Resultado (String)
Calif1 (String)
Calif2 (String)
Calif3 (String)
C
5
: ArticuloRegistrado
C
1
(Registro)
C
2
(Articulo)
Figura 6.2: Conjunto de colores
6.2.5. WfCCPN obtenida
En la gura 6.3 se muestra el proceso principal modelado a travs de WfCCPN. La marca
inicial es:
M(P
0
) = {(C
1
), (C
2
)}
El color de cada lugar se especica dentro del crculo que representa cada lugar, mientras
que una etiqueta P
indice
identica la posicin del lugar al cual nos referimos en la explicacin,
adems una etiqueta descriptiva con formato de letras itlicas se adjunta a cada lugar y
transicin de la red que modela el proceso principal la cual se muestra en la gura 6.3. El
proceso de workow es iniciado a travs de la regla ECA 1, la cual tiene un evento primitivo
inicio el cual representa el momento en que un token de color C
1
y un token de color C
2
son depositados en el lugar virtual de inicio P
0
, en donde la accin es el evento evento
AND_SPLIT(EnvioRegistro : EnvioArticulo) de la regla 2, la cual a su vez posee la
accin: ACTION_CREATE(ArticuloRegistrado) asociada a la transicin compuesta t
1
ser ejecutada si las estampas de tiempo de creacin de los tokens que pasen a travs de ella,
son menores la fecha lmite para el envo de artculos.
Si la accin es ejecutada el resultado ser reejado en el lugar compuesto P
5
, es decir el to-
ken de color compuesto creado por la accin ser depositado en P
5
, representando la recepcin
del artculo para su evaluacin por el comit revisor del congreso. La accin representada en
el lugar P
5
, es adems el evento activador AND_SPLIT(Regla_4 : Regla_5 : Regla_6)
el cual se representa a travs de la transicin copia la cual enva una copia del artculo y la
informacin de registro representadas a travs del token de color C
5
recientemente creado;
este evento representa el envo del articulo para su evaluacin a tres revisores, a travs de
transiciones tiempo que poseen retardos para su disparo es posible modelar el tiempo
2
que
le toma a cada revisor evaluar el artculo. Estas tres reglas se representan por los siguientes
elementos: Regla_4 = {P
6
, t
3
, p
9
}, Regla_5 = {P
7
, t
4
, p
10
} y Regla_6 = {P
8
, t
5
, p
11
}.
En los lugares compuestos P
12
, P
13
, P
14
se representan las tareas de revisin de los artculos
y sus resultados, generados por las acciones de las transiciones de los cuales son lugares de
salida, estas transiciones son t
6
, t
7
y t
8
y corresponden a las reglas 7, 8 y 9 respectivamente,
esas acciones crean los colores que contienen la informacin con el resultado de la evaluacin,
de esta manera los tokens son creados con el color C
3
que contienen la decisin de cada uno
de los revisores en su atributo C
3
.decisi on.
Una vez que se ha modelado la respuesta de los revisores, es posible modelar la noticacin
a los autores de artculos sobre la aceptacin o rechazo de sus propuestas. La regla ECA 10,
representa la noticacin, es decir el token de color C
4
que se deposita en el lugar P
15
el
2
El tiempo que se toma cada revisor en evaluar un artculo probablemente no sea de gran relevancia para
el proceso de workow modelado, sin embargo el objetivo es mostrar la manera de modelar tareas que tienen
un tiempo especico o aleatorio para ser realizadas.
108
inicio
PLAZO
sometimiento de artculos
Envo articulo
Rechazado
Aceptado
RESULTADO
Notificacin
Revisor 3
Revisor 2
Revisor 1
Evaluacin 1
Evaluacin 3
Eval. 2
C
5
C
5
C
5
C
5
C
3
C
3 C
3
C
4
C
1
C
2
Envo registro
Recepcin
C
3
P
0
P
2
P
1
P
16
P
17
P
3
P
5
P
6
P
7
P
8
P
9
P
10
P
11
P
12
P
13
P
14
P
15
t
1
t
0
t
2
t
3
t
4
t
5
t
6
t
7
t
8
t
9
t
10
t
11
P
3
P
4
Figura 6.3: Proceso principal.
cual es creado a partir de los valores en los tokens de color C
3
y que llegan a la transicin
compuesta t
9
.
El evento OR_SPLIT(SUB_NET(Aceptado) : SUB_NET(Rechazado)) de la regla
12 representa el envo de la noticacin al autor, a travs de la transicin copia t
11
se enva
una copia del token con la noticacin hacia los lugares de tipo subred p
16
y p
17
llamados
Aceptado y Rechazado. Las redes en que se sigue el proceso de workow contenidas en estos
dos lugares subred se presentan a continuacin
En la gura 6.3 se muestra el subproceso contenido dentro del lugar P
15
, el cual representa
la aceptacin del artculo. La regla 13 representa la noticacin de aceptacin a travs de
la condicin en la transicin regla t
1
, lo que provoca la espera del evento de la regla 14 el
cual ser activado hasta que el usuario deposite un token el cual representa la versin nal
del artculo, al tener un token el lugar p
1
y p
2
se disparar la regla 14, siempre y cuando
la condicin del plazo para el envo de las versiones nales sea cumplido por los tokens que
Preparacin de la
versin final
Envo notificacin
IF notificacin == aceptado
deferido
PLAZO versin final
Envo del articulo al editor
Fin
C
3
C
3
C
4
P
0
P
1
P
0
P
2
P
3
P
4
Inicio_s
t
1
t
2
t
3
t
4
Figura 6.4: Sub proceso de aceptacin.
llegan a la transicin t
2
, depositando un token de color C
3
el cual representa la accin de la
recepcin de la versin nal del artculo. Una vez que se recibe el artculo se genera el evento
de la regla 15, con lo cual el artculo es enviado al editor de las memorias del congreso en
donde sern publicados todos los artculos, llegando as al nal del proceso de workow.
Por otro lado cuando el artculo es rechazado el subproceso Rechazado se ejecuta, simple-
mente enviando el mismo token hacia un lugar de cancelacin y posteriormente a un lugar
primitivo n, con lo que el proceso de workow se cancela.
En la gura 6.6 se muestra el modelo generado en WfECAPNSim.
110
Cancela
Fin
Envo notificacin
IF notificacin == rechazado
P
0
P
1
P
2
t
1
Figura 6.5: Sub proceso de cancelacin del proceso de workow
Figura 6.6: Proceso modelado en el sistema WfECAPNSim
6.3 Comentarios nales 111
Este captulo present a travs de un ejemplo el enfoque de modelado propuesto al utilizar
las WfCCPN para modelar procesos de workow. Como ejemplo se utiliz el conjunto de
reglas ECA identicadas en el proceso general que se lleva a cabo en la seleccin de artculos
cientcos para su publicacin en un congreso cientco.
112
Captulo 7
Conclusiones
En este captulo se presenta de forma general los resultados obtenidos con la realizacin
de este trabajo de tesis. Tambin se presentan sugerencias referentes a posible trabajo futuro
para mejorar y extender los resultados obtenidos. El captulo se estructura de la siguiente
forma: la seccin 7.1 presenta los resultados obtenidos as como las aportaciones principales
del trabajo realizado; la seccin 7.2 expone las actividades propuestas para mejorar y extender
las WfCCPNs y el sistema WfECAPNSim adems los temas en que es posible continuar la
investigacin con respecto a la tecnologa Workow.
7.1. Resultados obtenidos
En este trabajo de tesis se present una propuesta para modelar y simular procesos de
workow a travs de una extensin de redes de Petri coloreadas condicionales, con esta es
posible modelar la perspectiva de ujo de control sin necesidad de abstraer datos de control
como se hace en [13]. A las CCPN originales fueron agregados elementos extras a partir de
lo estudiado en trabajos tales como [15], [32], [9], [10], con estos elementos se modelan los
conceptos de workow de acuerdo al modelo de referencia del WfMC (Workow Management
Coalition), adems se modelan los patrones de ujo de control que han sido propuestos como
marcos de trabajo que permiten evaluar metodologas de modelado para procesos de workow,
en este trabajo se implementaron dichos patrones y se presentaron en el captulo 4, obteniendo
como resultado, la posibilidad de modelar todos los patrones de ujo de control a travs de
WfCCPN. El hecho de que los estndares existentes y los principales WfMS que existen
actualmente nicamente modelen entre once y catorce patrones (con excepcin del Sistema
114 Conclusiones
YAWL
1
), permite considerar como satisfactoria la aplicacin de las WfCCPN en el modelado
de este tipo de procesos, ya que adems permite modelar de acuerdo a las deniciones de la
WfMC y como parte adicional al objetivo del trabajo (modelar completamente la perspectiva
de ujo de control) fue posible modelar de manera parcial la perspectiva de datos a travs de
los colores en los tokens de la WfCCPN. Se considera que no se tiene un soporte total para la
perspectiva de datos debido a que no se utilizaron las variables de manera completa, ya que
nicamente se utiliz una variable contador en cada transicin de la WfCCPN, con el uso
de un nmero n de variables en las transiciones se aumenta la exibilidad de la WfCCPN e
incluso la implementacin de algunos patrones de ujo de control se realiza de manera ms
compacta.
Adems de los constructores de enrutamiento los cuales se modelan como eventos de una
regla ECA, es posible utilizar los eventos compuestos implementados con CCPNy presentados
en [20], con lo que se obtiene mayor capacidad de modelado para los procesos de workow, por
ejemplo con el evento secuencia con el cual es posible establecer el orden necesario de ejecucin
de un conjunto de tareas en un proceso de workow, no se contempla en los patrones de ujo
de control propuestos hasta la fecha, as como tampoco se encontraron implementaciones
similares en los sistemas de software estudiados.
La aplicacin de reglas ECA en Workow ha sido utilizada en el modelado, en la ejecucin
y en el manejo de excepciones de procesos de workow, sin embargo son pocos los trabajos
realizados a la fecha y como se menciona en [30] el enfoque de reglas ECA no ha sido
muy utilizado en los WfMS comerciales debido a la dicultad que presenta el generar las
reglas ECA de manera manual (gramaticalmente). Con WfECAPNSim la tarea de generar
las reglas ECA que representan al proceso de workow es realizada de manera grca a travs
de la extensin realizada a las CCPN las cuales fueron desarrolladas especialmente para la
representacin de reglas ECA, con lo que la dicultad de crear el conjunto de reglas ECA se
facilita al tener una perspectiva grca en los elementos de la WfCCPN los cules permiten
identicar de manera intuitiva las partes de una regla ECA.
A travs de utilizar transiciones que toman en cuenta el tiempo, es posible retardar
disparos y vericar intervalos de tiempo vlidos con lo que la metodologa propuesta con
WfCCPN se extiende el uso de reglas ECA en su dimensin para validacin de tiempos.
1
El sistema YAWL modela 19 patrones, en esta tesis se present que debido a que YAWL slo considera un
punto de nalizacin del workow, no es posible que este modele el patrn de terminacin implcita descrito
en el captulo 4.
7.2 Trabajo futuro 115
De los sistemas comerciales que aplican el enfoque de reglas ECA ninguno proporciona la
capacidad de utilizar la dimensin de tiempos vlidos de las reglas ECA [38].
Adems de modelar procesos de workow con caractersticas de tiempo, es posible mode-
larlos de manera jerrquica lo que proporciona la posibilidad de modelar procesos de workow
de un tamao considerable, las dos caractersticas anteriores son necesarias para la simulacin
del proceso a travs del juego de tokens de la red obtenida, sin embargo en cuanto a simula-
cin puede resultar difcil la visualizacin de procesos grandes, debido a la restriccin natural
en cuanto a tamao de visualizacin en una computadora.
Finalmente otro resultado y contribucin del trabajo realizado es el software WfECAP-
NSim, el cual permite modelar procesos de workow y ver su comportamiento a travs de la
simulacin que ofrece el sistema, el WfECAPNSim provee caractersticas que difcilmente se
encuentran en los sistemas de software gratuitos, tales como modelar caractersticas de jerar-
qua, de tiempo y de manejo de colores, adems de simular el proceso modelado, en algunos
casos se encuentra una u otra caracterstica pero no todas, a excepcin de YAWL el cual
proporciona las caractersticas citadas. Sin embargo en sistemas de software comerciales es
ms comn encontrar dichas caractersticas. De esta manera la implementacin desarrollada
contribuye con una herramienta de software gratuita la cual puede obtenerse y modicarse
o extenderse de manera libre.
7.2. Trabajo futuro
El trabajo a futuro que es sugerido a partir del trabajo realizado y de los resultados
obtenidos se presenta a continuacin:
Ampliar la metodologa con el n de modelar de manera total la perspectiva de datos.
Investigar la factibilidad para que a travs de WfCCPN se modele tambin la perspecti-
va de recursos (conocida tambin como perspectiva organizacional) y otras perspectivas
de manera completa, como la de tratamiento de excepciones.
Continuar el desarrollo del sistema WfECAPNSim con mejoras como las siguientes:
Manejo de variables en las transiciones, Ampliar el conjunto de acciones, Reportes de
la simulacin a mayor detalle, e implementacin de mtodos matemticos de anlisis y
validacin ms completos.
116 Conclusiones
Modelar procesos de workow mucho ms complejos con el n de continuar mejorando
la metodologa propuesta y el sistema desarrollado.
La investigacin sobre Workow y CCPN puede extenderse al desarrollo de un motor
de workow, el cual pueda representar y ejecutar los procesos modelados con el sistema
WfECAPNSim, proponiendo as la ejecucin automtica de los procesos de workow
en base a la traduccin de las reglas ECA, estas a travs del sistema ECAPNSim con su
mdulo de conexin a base de datos y ejecucin de reglas ECA pueden ser ejecutadas
en una base de datos relacional.
La tecnologa Workow es bastante extensa, por lo que los puntos anteriores son sugeridos
para su realizacin debido a que se consideran como factibles a partir del trabajo que ha sido
desarrollado en la presente tesis y en otras tesis en las que se utilizan las CCPNs.
Publicaciones
Artculo 1
Ttulo: "Modelado de workows utilizando redes de Petri coloreadas condicionales".
Congreso: 12vo. Congreso Internacional de Investigacin en Ciencias Computacionales
(CIICC05), Monterrey, Mxico, 15-17 de Noviembre de 2005.
Autores: Samuel Garrido-Daniel, Xiaoou Li, Joselito Medina-Marn.
Artculo 2
Ttulo: "WfECAPNSim: Sistema para modelado y simulacin de procesos workow".
Congreso: Congreso nacional de Informtica y Sistemas Computacionales (CONAIS 2005).
Villahermosa, Tabasco, Mxico 31 de Agosto, 1 y 2 de septiembre.
Artculo 3
Ttulo: "Modelacin y simulacin de procesos workow utilizando redes de Petri".
Congreso: I Congreso sobre Ingeniera e Investigacin Cientca (CONIIC 2005). Lima-
Per. 19 - 22 de Octubre.
118
Bibliografa
[1] David Hollingsworth. The Workow Reference Model.
[2] Sitio web del workow management coalition. www.wfmc.org.
[3] The global business process management community. www.bpmg.org.
[4] The association of business process management professionals. www.abpmp.org.
[5] Portal workow. www.e-workflow.org.
[6] Workow research. www.workflow-research.de.
[7] Eshuis. Hendrik. Semantics and Verication of UML Activity Diagrams for Workow
Modelling. PhD thesis, University of Twente, Enschede, The Netherlands, 2002.
[8] Wohed. Petia, W. M. P van der Aalst, Dumas. Marlon, A. H. M. ter Hofstede, and
Russell. Nick. Pattern-based analysis of uml activity diagrams. In K. Jensen, editor,
Proceedings of the Fourth Workshop on the Practical Use of Coloured Petri Nets and
CPN Tools (CPN 2002), volume 560 of DAIMI, pages 120, Aarhus, Denmark, August
2002.
[9] van der Aalst. Wil M. P. and ter Hofstede. Arthur H. M. Yawl: Yet another workow lan-
guage. QUT Technical Report FIT-TR-2003-04, Queensland University of Technology,
2003.
[10] Stork. David and van Glabbeek. Rob. Token-controlled place renement in hierarchical
petri nets with application to active document workow. In ICATPN 02: Proceedings
of the 23rd International Conference on Applications and Theory of Petri Nets, pages
394413, London, UK, 2002. Springer-Verlag.
[11] Thomas Jacob, Olaf Kummer, Daniel Moldt, and Ulrich Ultes-Nitsche. Implementation
of Workow Systems using Reference Nets Security and Operability Aspects. In Kurt
120 BIBLIOGRAFA
Jensen, editor, Fourth Workshop and Tutorial on Practical Use of Coloured Petri Nets
and the CPN Tools, Ny Munkegade, Bldg. 540, DK-8000 Aarhus C, Denmark, August
2002. University of Aarhus, Department of Computer Science. DAIMI PB: Aarhus,
Denmark, August 2830, number 560.
[12] Zhu Li. Haiping and Zhang Guojun. Peigen. Htsn: A complex workow model based on
colored petri net. Journal of Computer Science and Technology, 4(1):7, April 2004.
[13] van der Aalst. Wil M. P. and van Hee. Kees. Workow Management. Models, Methods,
and Systems. MIT Press, Cambridge, MA, 2002.
[14] Eshuis. Hendrik and Dehnert. Juliane. Reactive petri nets for workow modeling. In
ICATPN, pages 296315, 2003.
[15] Kiepuszewski. Bartosz. Expressiveness and Suitability of Languages for Control Flow
Modelling in Workows. PhD thesis, Queensland University of Technology, Brisbane,
Australia, 2002.
[16] Workow patterns group. The workow patterns page. this site serves as a repository
for workow modeling patterns. http://www.workflowpatterns.com.
[17] Sitio web principal sobre redes de petri. www.daimi.au.dk/PetriNets/.
[18] Sitio web principal sobre redes de petri coloreadas. www.daimi.au.dk/CPnets/.
[19] Li. Xiaoou and Medina Marin. Joselito. Composite event specication in active database
systems: A petri net approach. In Fifth Workshop and Tutorial on Practical Use of
Coloured Petri Nets and the CPN Tools Aarhus, Denmark, DAIMI PB - 570, ISSN
0105-8517, October 2004.
[20] Medina Marin, J. Red de PetriColoreada Condicional (CCPN) y su Aplicacin en Bases
de Datos Activas. PhD thesis, CINVESTAV-IPN, September 2002.
[21] Hollingsworth. David. The workow reference model version 1.1. Technical Report
WFMC-TC-1003, Workow Management Coalition, January 19th 1995.
[22] G.J. Houben W.M.P. van der Aalst, K.M. van Hee. Modelling and analysing workow
using a petri-net based approach. 2(2):98132, 1998.
BIBLIOGRAFA 121
[23] Kiepuszewski. Bartosz, Hofstede. Arthur, and van der Aalst. Wil. Fundamentals of
control ow in workows. B. Kiepuszewski, A.H.M. ter Hofstede, and W.M.P. van der
Aalst. Fundamentals of Control Flow in Workows. QUT Technical report, FIT-TR-
2002-03, Queensland University of Technology, Brisbane., 2002.
[24] Casati. Fernando, S. Ceri, B. Pernici, and G. Pozzi. An environment for designing
exceptions in workows. Information Systems, vol. 24, no. 3, pp. 255-273,, May 1999.
[25] Harald Strrle. Semantics and verication of data ow in uml 2.0 activities. Elsevier,
77(1):5, April 2004.
[26] Tadao Murata. Petri nets: Properties, analysis and applications. Proceedings of the
IEEE, 77(4):541580, Abril 1989.
[27] K. Jensen. An introduction to the practical use of coloured petri nets. In Lectures
on Petri Nets II: Applications, Lecture Notes in Computer Science, volume 1492, pages
237292. Springer Verlag, 1998.
[28] Lars Michael Kristensen, Soren Christensen, and Kurt Jensen. The practitioners guide
to coloured petri nets. International Journal on Software Tools for Technology Transfer,
2(2):98132, 1998.
[29] Dickson K. W. Chiu, Qing Li, and Kamalakar Karlapalem. A meta modeling approach
to workow management systems supporting exception handling. Information Systems,
24(2):159184, 1999.
[30] Bae. Joonsoo, Bae. Hyreim, Kang. Suk-Ho, and Yeongho. Kim. Automatic workow
processes using eca rules. IEEE Transactions on knowledge and data engineering, Vol.
16, No. 8, August 2004.
[31] Casati. Fernando, S. Ceri, B. Pernici, and G. Pozzi. Deriving active rules for workow
enactment. Proc. Seventh Intl Conf. Database and Expert Systems Applications, pp.
94-110, 1996.
[32] Zhou. Jiantao, Shi. Meilin, and Ye, Xinming. On pattern-based modeling for multiple
instances of activities in workows. Agosto 2003.
[33] van der Aalst. Wil M. P., Arthur H. M. ter Hofstede, Bartek Kiepuszewski, and Alistair P.
Barros. Workow patterns. Distributed and Parallel Databases, 14(3):551, 2003.
122 BIBLIOGRAFA
[34] Workow research. www.manageability.org/blog/stuff/workflow
i
n
j
ava/view.
[35] Workow research. java-source.net/open-source/workflow-engines.
[36] Sitio web del sistema woped. www.woped.org.
[37] Sitio web del sistema bossa. www.bossa.org.
[38] Robert Mller, Ulrike Greiner, and Erhard Rahm. Deriving active rules for workow
enactment. Data Knowledge Engineering, 14(3):551, 2004.

Tesis Workflow

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tesis Workflow

Încărcat de

Drepturi de autor:

Formate disponibile

Ci:1no i I:\i1io.cio: . i L1io A\.:z.

S-ar putea să vă placă și