MOTORDEEJECUCION¶ DEREDESDEPETRI · y ejecutar redes de Petri, de modo que ¶estas puedan...
Transcript of MOTORDEEJECUCION¶ DEREDESDEPETRI · y ejecutar redes de Petri, de modo que ¶estas puedan...
MOTOR DE EJECUCION DE REDES DE PETRI
Br. Demian Gutierrez
Tutor: Prof. Edgar Chacon
COMO REQUISITO PARA OBTENER
EL GRADO DE
INGENIERO DE SISTEMAS
DE LA
UNIVERSIDAD DE LOS ANDES
MERIDA, VENEZUELA
ABRIL 2004
c© Copyright de Universidad de Los Andes, 2004
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERıA
El jurado aprueba el proyecto de grado titulado
“Motor de Ejecucion de Redes de Petri” realizado por
Br. Demian Gutierrez como requisito parcial para la obtencion
del grado de Ingeniero de Sistemas.
Fecha: Abril 2004
Tutor:Prof. Edgar Chacon
Jurado:Prof. Eladio Dapena
Prof. Juan Cardillo
CYRANO: Pero, perdon; tengo que irme; no puedo
hacer esperar a ese rayo de luna que viene a llevarme.
(Edmundo Rostand, 1897, Cyrano de Bergerac)
Indice general
Indice de Tablas IX
Indice de Figuras X
Agradecimientos XIII
Resumen XV
1. Introduccion 1
1.1. Sistemas de Eventos Discretos . . . . . . . . . . . . . . . . . . . . 1
1.2. Definicion del Problema . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Motor de Ejecucion de Redes de Petri . . . . . . . . . . . . . . . . 3
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . 4
1.5. Descripcion de los Siguientes Capıtulos . . . . . . . . . . . . . . . 4
2. Redes de Petri 5
2.1. Introduccion a las Redes de Petri . . . . . . . . . . . . . . . . . . 5
2.1.1. Definicion Informal de una Redes de Petri . . . . . . . . . 5
2.1.2. Definicion Formal de una Red de Petri . . . . . . . . . . . 7
2.1.3. Notacion Matricial de una Red de Petri . . . . . . . . . . . 8
2.1.4. Red de Petri Pura . . . . . . . . . . . . . . . . . . . . . . 9
2.1.5. Habilitacion de una Transicion . . . . . . . . . . . . . . . . 10
v
2.1.6. Disparo de una Transicion . . . . . . . . . . . . . . . . . . 11
2.1.7. Conflicto Estructural y Efectivo . . . . . . . . . . . . . . . 12
2.1.8. Secuencia de Disparo . . . . . . . . . . . . . . . . . . . . . 13
2.1.9. Conjunto de Marcaciones Accesibles . . . . . . . . . . . . . 14
2.1.10. Redes de Petri Acotadas . . . . . . . . . . . . . . . . . . . 14
2.2. Redes de Petri con Arcos Inhibidores . . . . . . . . . . . . . . . . 15
2.3. Maquinas de Estado y Redes de Petri . . . . . . . . . . . . . . . . 16
2.4. Redes de Petri de Alto Nivel . . . . . . . . . . . . . . . . . . . . . 17
3. Modelo Ampliado de Redes de Petri 21
3.1. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Transiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Problemas de Conflicto . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Transicion Simple . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3. Transicion Generadora de Eventos . . . . . . . . . . . . . . 27
3.2.4. Transicion Asociada a Codigo Java . . . . . . . . . . . . . 28
3.3. Lugares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1. Marcacion de un Lugar . . . . . . . . . . . . . . . . . . . . 29
3.3.2. Lugar de Fichas . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Lugar de Fichas Coloreadas . . . . . . . . . . . . . . . . . 31
3.3.4. Lugar Asociada a Codigo Java . . . . . . . . . . . . . . . . 31
3.4. Aristas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1. Arista de Fichas . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2. Arista de Fichas Coloreadas . . . . . . . . . . . . . . . . . 33
3.4.3. Arista Simple . . . . . . . . . . . . . . . . . . . . . . . . . 33
4. Arquitectura del Sistema 35
4.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2. Arquitectura General del Sistema . . . . . . . . . . . . . . . . . . 37
4.2.1. El Motor de Ejecucion . . . . . . . . . . . . . . . . . . . . 37
4.2.2. Ciclo de Vida de una Red de Petri . . . . . . . . . . . . . 38
4.2.3. Interfaz Remota y Local . . . . . . . . . . . . . . . . . . . 40
4.2.4. El Editor de Redes de Petri . . . . . . . . . . . . . . . . . 40
4.2.5. Los Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3. Arquitectura del Motor . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1. Capturador de Eventos . . . . . . . . . . . . . . . . . . . . 41
4.3.2. Repositorio de Redes de Petri . . . . . . . . . . . . . . . . 42
4.3.3. Manejador de Eventos . . . . . . . . . . . . . . . . . . . . 43
4.3.4. Manejador de Sucesos . . . . . . . . . . . . . . . . . . . . 43
4.3.5. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4. Arquitectura del Editor . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1. Interfaz Principal . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2. Interfaz de Administracion . . . . . . . . . . . . . . . . . . 45
4.4.3. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.4. Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5. Implementacion 47
5.1. El API de Componentes . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1. Data del Componente ComponentData . . . . . . . . . . . 48
5.1.2. Objeto Acuarela ComponentObject . . . . . . . . . . . . . 49
5.1.3. Objeto de Ejecucion ComponentRuntime . . . . . . . . . . 51
5.1.4. Fabrica de Componentes ComponentFactory . . . . . . . . 52
5.1.5. Archivo Descriptor de Componentes . . . . . . . . . . . . . 53
5.2. El Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1. Representacion del Documento en Memoria . . . . . . . . 53
5.2.2. Representacion del Documento en XML . . . . . . . . . . 54
5.3. El Motor de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1. Interfaz de Administracion, Capturador de Eventos . . . . 56
5.3.2. Manejador de Sucesos . . . . . . . . . . . . . . . . . . . . 58
5.3.3. Repositorio de Redes de Petri . . . . . . . . . . . . . . . . 58
5.3.4. Manejador de Eventos . . . . . . . . . . . . . . . . . . . . 60
5.4. El Editor de Redes de Petri . . . . . . . . . . . . . . . . . . . . . 62
5.4.1. Clases del Editor de Redes de Petri . . . . . . . . . . . . . 63
6. Conclusiones y Recomendaciones 65
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A. Definicion de Redes de Petri en XML 71
B. Tecnologıas y Terminos mas Comunes en Java 77
C. Acronimos 81
Bibliografıa 82
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Indice de figuras
1.1. Sistemas: a) Continuos, b) Eventos Discretos . . . . . . . . . . . . 2
2.1. Componentes de una Red de Petri . . . . . . . . . . . . . . . . . . 6
2.2. Ejemplo de una Red de Petri . . . . . . . . . . . . . . . . . . . . 6
2.3. Una Red de Petri que Representa Recursos y Actividades . . . . . 7
2.4. Una Red de Petri no Pura . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Habilitacion de una Transicion . . . . . . . . . . . . . . . . . . . . 11
2.6. Disparo de una Transicion . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Conflicto: a) Estructural, b) Efectivo . . . . . . . . . . . . . . . . 13
2.8. Marcaciones Accesibles de una Red de Petri . . . . . . . . . . . . 14
2.9. Efecto de un Arco Inhibidor: a) t1 Deshabilitada, b) t1 Habilitada 16
2.10. Red de Petri con un Numero Infinito de Estados . . . . . . . . . . 17
2.11. Marcaciones Accesibles (infinitas) de una red de Petri . . . . . . . 18
2.12. Red de Petri de Alto Nivel . . . . . . . . . . . . . . . . . . . . . . 19
2.13. Comparacion Entre Redes de Petri y Lenguajes de Programacion 20
3.1. Disparo de una Transicion . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Conflicto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Transicion Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Transicion Generadora de Eventos . . . . . . . . . . . . . . . . . . 27
3.5. Situacion de Lazo Infinito . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Transicion Asociada a Codigo Java . . . . . . . . . . . . . . . . . 29
3.7. Lugar de Fichas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
xi
3.8. Lugar de Fichas Coloreadas . . . . . . . . . . . . . . . . . . . . . 31
3.9. Lugar Asociado a Codigo Java . . . . . . . . . . . . . . . . . . . . 32
4.1. Arquitectura General del Sistema . . . . . . . . . . . . . . . . . . 37
4.2. Ciclo de Vida de una Red en el Motor . . . . . . . . . . . . . . . 39
4.3. Arquitectura del Motor . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. Arquitectura del Editor . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1. Diagrama de Clases del API de Componentes . . . . . . . . . . . 48
5.2. Diagrama de Clases de los Objetos Acuarela Predeterminados . . 50
5.3. Diagrama de Clases de los Renderers Acuarela Predeterminados . 51
5.4. Diagrama de Clases del Documento . . . . . . . . . . . . . . . . . 54
5.5. Diagrama de Clases de la Interfaz del Motor . . . . . . . . . . . . 57
5.6. Diagrama de Clases del Motor . . . . . . . . . . . . . . . . . . . . 59
5.7. Ejecucion de un Evento (Primera Etapa) . . . . . . . . . . . . . . 61
5.8. Ejecucion de un Evento (Segunda Etapa) . . . . . . . . . . . . . . 62
5.9. Diagrama de Clases del Editor . . . . . . . . . . . . . . . . . . . . 63
Agradecimientos
A mis dos grandes amores: Glorianna e IDE. A ti Glori, gracias por tu
ternura y tu amor. A ti Iride, gracias por todo lo que me has dado, por tu amor
y apoyo incondicional, sin ti no hubiera llegado a la meta. Las amo. Son la luz de
mi vida.
A mis padres, quienes tambien recorrieron este camino conmigo, se plantea-
ron la meta de traerme hasta aquı y lo lograron.
A Minotauro, un sueno que se convirtio en mi segundo hogar.
A mi compadre Esteban Anez, gracias por tu apoyo y solidaridad, pero
sobre todo, gracias por el carino que le das a mi familia.
A mis companeros de trabajo: Cucho, Orlando y Angel, gracias por su
amistad y companerismo. Son como mis hermanos. Es un honor trabajar con
ustedes.
A todos aquellos profesores que ayudaron en mi formacion: Pero
especialmente a Leandro, Rafael, Eladio, Edgar. A todos ustedes; Gracias!
A la ULA, gracias por haberme aceptado y acogido en su recinto. Gracias
a esta oportunidad, pude aprender muchas cosas sobre mi carrera, crecer como
persona y convertirme en un futuro profesional.
xiii
Resumen
Este documento propone y desarrolla un motor de ejecucion de redes de Petri.
El objetivo fundamental del motor es su utilizacion para modelar sistemas de
eventos discretos (utilizando dichas redes) para un sistema de gestion de holones
y para sistemas de manufactura holonicos. Sin embargo, el motor se concibe de
la forma mas amplia posible, como un software de proposito general que permita
modelar y ejecutar cualquier tipo de redes de Petri. Tales resultados se logran
por medio de una arquitectura facilmente expandible y escalable basada en el
concepto de componentes o plug-ins, que pueden ser desarrollados e insertados
en el motor de ejecucion segun van surgiendo nuevas necesidades.
Descriptores Cota
Sistemas de control de supervision *
Redes de Petri TJ222
G88
xv
Capıtulo 1
Introduccion
1.1. Sistemas de Eventos Discretos
En general, todo sistema tiene asociada una dinamica que representa los cam-
bios que pueden ocurrir en las variables del mismo. De forma que los diferentes
elementos de un sistema evolucionan de acuerdo a un conjunto de leyes propias
que describen su evolucion natural, bien sea fısica o quımica, y que puede ser del
tipo x = f(x, u), en el caso de que el sistema sea continuo, o xk+1 = ft(xk, σk)
si el sistema es de dinamica discreta. Un caso especial se presenta en los siste-
mas hıbridos, que se componen de elementos continuos y elementos discretos.
En principio, existen muchas herramientas y tecnicas para modelar y predecir la
dinamica continua y discreta de un sistema. Sin embargo, desde el punto de vista
de los sistemas de eventos discretos, una que ha resultado especialmente exitosa
ha sido la utilizacion de redes de Petri.
En la Figura 1.1-b se muestra un ejemplo de la dinamica de un sistema de
eventos discretos. En este tipo de sistemas, el estados del mismo (lineas horizon-
tales) cambian bruscamente en instantes especificos de tiempo. Estos cambios,
generalmente, estan asociados a eventos o sucesos dentro del sistema, y no siem-
pre puede predecirse el momento en que ocurren.
2 Introduccion
t
t
a)
b)
Figura 1.1: Sistemas: a) Continuos, b) Eventos Discretos
1.2. Definicion del Problema
En los sistemas de eventos discretos es especialmente util poder seguirle la
pista a la evolucion del sistema para poder obtener informacion respecto al estado
del mismo. Si un sistema de produccion es pequeno (por ejemplo, una fabrica de
pequena envergadura) es relativamente sencillo saber cual es el estado del mismo,
es decir, que maquinas estan disponibles, que se esta produciendo, en que etapa
de produccion se encuentra la fabrica, etc. Sin embargo, cuando el sistema de
produccion crece un poco, ya no es facil determinar a simple vista la situacion
exacta en la que se encuentra. Es por esto que resulta util seguirle la pista al
sistema a medida que este va cambiando, para que en un momento dado, sea
posible tener una idea clara del estado del mismo.
La vision “panoramica” de los sistemas de eventos discretos, brindada por
las redes de Petri, permite entre otras cosas agilizar el flujo de informacion de
las capas mas bajas a las mas altas de los sistema de produccion. Esto hace que
el sistema se vuelva mas eficiente y pueda responder con mayor rapidez a las
1.3 Motor de Ejecucion de Redes de Petri 3
eventualidades que ocurran durante el proceso de produccion. Por otra parte, al
tener una vision mas amplia del sistema, es posible tomar decisiones de forma
mas inteligente, incluyendo rapidamente factores que de otro modo no hubieran
sido posible considerar. Por esta razon, serıa util contar con una herramienta que
permita modelar y supervisar este tipo de sistemas, haciendo que la misma se
ejecute y evolucione en paralelo con el sistema real.
1.3. Motor de Ejecucion de Redes de Petri
El motor de ejecucion de redes de Petri es una herramienta capaz de simular
y ejecutar redes de Petri, de modo que estas puedan acoplarse a un sistema
de eventos discretos. De esta forma, un sistema de eventos discretos modelado
utilizando este tipo de redes, puede acoplarse al motor, siendo posible hacer que el
modelo evolucione al recibir estımulos del sistema real, en paralelo con el mismo.
En general, esto resuelve el problema planteado en la seccion 1.2. Ademas, el
motor permite modelar y ejecutar sistemas discretos que no son “reales”, es decir,
que no existen en el mundo fısico como tales, pero si en el mundo del computador
digital. Basicamente, esto ultimo hace que el motor de redes de Petri se convierta
en una herramienta de diseno poderosa en el mundo del desarrollo de software,
ya que permite modelar e implantar facilmente procesos (que en el fondo son
sistemas de eventos discretos) que de otra forma serıan mucho mas complejos de
codificar.
1.4. Objetivos
1.4.1. Objetivo General
Esta tesis plantea la construccion de un motor de ejecucion de redes de Petri de
proposito general, que pueda ser utilizado a largo plazo para el analisis, modelado,
verificacion y supervision de sistemas de eventos discretos.
4 Introduccion
1.4.2. Objetivos Especıficos
Definicion de un formato de archivo XML que permita describir redes de
Petri.
Definicion de una estructura de datos que permita manipular redes de Petri.
Diseno e implementacion de una arquitectura de componentes y plug-ins
para el motor de ejecucion y el editor de redes de Petri.
Diseno e implementacion del motor de ejecucion de redes de Petri.
Diseno e implementacion del editor de redes de Petri.
1.5. Descripcion de los Siguientes Capıtulos
El capıtulo 2 sirve de base en lo referente a la teorıa basica de redes de Petri y el
mismo tiene su origen, en buena parte, en las publicaciones realizadas al respecto
por Janette Cardoso y Robert Valette (ver referencias bibliograficas). Por otra
parte, el capıtulo 3 propone un modelo “ampliado” de redes de Petri, por medio
del cual se puedan expandir este tipo de redes a gusto, segun sean las necesidades
del problema que se desea solucionar. Este capıtulo, ademas, plantea algunos de
los posibles inconvenientes y dificultades, tanto generales como particulares que
es posible encontrar al enfrentarse a los distintos componentes de dicho modelo.
Desde este punto en adelante, comienzan abiertamente las tareas de diseno y
desarrollo del sistema, definiendo y proponiendo en el capıtulo 4 la arquitectura
del motor de ejecucion. Por otra parte, los detalles particulares a la implantacion
del software son definidos en el capıtulo 5, donde se aprecian detalles importan-
tes sobre el modelo de componentes, que resulta ser un punto clave a lo largo del
desarrollo del proyecto. Finalmente, en el capıtulo 6 se expresan algunas conclu-
siones finales y se hacen recomendaciones que pueden permitir mejorar futuras
versiones del sistema.
Capıtulo 2
Redes de Petri
Segun (Janette Cardoso, Robert Valette, 1997), las redes de Petri son una
herramienta grafica y matematica que se adapta bien a un gran numero de apli-
caciones en que las nociones de eventos, estados y evoluciones simultaneas son
importantes.
Fueron inventadas por Carl Adam Petri en 1962, en su tesis de doctorado
titulada Comunicacion con Automatas (C. A. Petri. Kommunikation mit Au-
tomaten. PhD thesis, Institut fur instrumentelle Mathematik, Bonn, 1962). En
general, fueron objeto de uso teorico hasta los 1980s, momento a partir del cual
se incremento su uso practico, debido principalmente a la introduccion de las
redes de Petri de alto nivel y la disponibilidad de herramientas de software que
manejaban este tipo de redes.
Algunas de las aplicaciones de las redes de Petri son: Analisis y verificacion
formal en los sistemas discretos, protocolos de comunicacion, sistemas de trans-
porte, control de sistemas de produccion y sistemas de informacion, entre otros.
6 Redes de Petri
2.1. Introduccion a las Redes de Petri
2.1.1. Definicion Informal de una Redes de Petri
Una red de Petri es un grafo dirigido bipartito que esta formado por dos tipos
de nodos llamados lugares y transiciones. Los nodos estan conectados por medio
de arcos, y no esta permitido que dos nodos del mismo tipo esten conectados
entre sı. Normalmente, un lugar se representa con un cırculo, una transicion con
un cuadrado (algunas notaciones utilizan un rectangulo o lınea horizontal) y los
arcos con flechas dirigidas (ver Figura 2.1).
Lugar ArcoTransiciones
Figura 2.1: Componentes de una Red de Petri
La Figura 2.2 muestra un ejemplo simple de una red de Petri, formada por las
transiciones t1, t2 y t3 y los lugares p1, p2, p3 y p4. La transicion t3, por ejemplo,
tiene dos lugares de entrada (p2 y p3) y dos lugares de salida (p3 y p4). Los arcos
dirigidos se encargan de definir con que lugares (entrada y salida) esta asociada
una transicion. En este caso, en particular, p3 es tanto un lugar de entrada de t3
como un lugar de salida.
p1
p2
p3
p4
[2]t1
t2
t3
Figura 2.2: Ejemplo de una Red de Petri
Los lugares de una red de Petri pueden tener fichas, las cuales se denotan
2.1 Introduccion a las Redes de Petri 7
utilizando puntos dentro del cırculo que representa el lugar que las contiene. En
el ejemplo de la Figura 2.2, los lugares p1 y p4 tienen una ficha cada uno, p2 tiene
dos fichas y p3 ninguna.
2.1.2. Definicion Formal de una Red de Petri
Existen, a lo largo de la literatura, muchos tipos de redes y muchas maneras
de definirlas formalmente. En general, todas son bastante similares, y difieren
solo en pequenos detalles. Sin embargo, la mas adecuada para los propositos de
esta tesis define una red de Petri R como una quıntupla:
R = (P, T, Pre, Post,M) (2.1)
En donde:
P es un conjunto finito de lugares de dimension n.
T es un conjunto finito de transiciones de dimension m.
Pre : P × T → N es una aplicacion de entrada (pre-condiciones).
Post : P × T → N es una aplicacion de salida (post-condiciones).
M : P → N es una aplicacion de marcacion.
La quıntupla R = (P, T, Pre, Post,M) con los lugares P = {p1, p2, p3}, las
transiciones T = {t1, t2, t3, t4}, los valores de entrada Pre(p2, t3) = 3, Pre(p1, t2) =
Pre(p2, t1) = Pre(p3, t4) = 1 y de salida Post(p1, t1) = Post(p2, t2) = Post(p3, t3) =
1, Post(p2, t3) = 3, junto con M(p1) = M(p3) = 1 y M(p2) = 3 representa a la
red de Petri mostrada en la Figura 2.3.
Ademas, se dice que M(p) es el numero de fichas que contiene el lugar p. La
marcacion M de una red de Petri es la distribucion de fichas alrededor de los
lugares de la red. La marcacion de la red en un momento determinado define el
estado de la red en dicho instante.
8 Redes de Petri
[3]
[3]
p2p1
t1
t2
p3
t3
t4
Figura 2.3: Una Red de Petri que Representa Recursos y Actividades
2.1.3. Notacion Matricial de una Red de Petri
Es posible escribir las aplicaciones Pre y Post de la equacion 2.1 en forma
matricial. Esto es consistente con la definicion de una red de Petri como un grafo
dirigido bipartito. Desde ese punto de vista, se pueden definir las matrices Pre y
Post de una red, y estas se pueden ver como las matrices de adyacencia del grafo
dirigido bipartito. Por ejemplo, para la red de la Figura 2.3, las matrices Pre y
Post son:
t1 t2 t3 t4
Pre =
0 1 0 0
1 0 3 0
0 0 0 1
p1
p2
p3
(2.2)
t1 t2 t3 t4
Post =
1 0 0 0
0 1 0 3
0 0 1 0
p1
p2
p3
(2.3)
Ademas, se define la matriz caracterıstica, o de incidencia, C de la red como:
C = Post− Pre (2.4)
Dicha matriz proporciona el balance (movimiento neto) de las fichas en la red
al momento de dispararse alguna transicion. Para la Figura 2.3, tenemos que la
2.1 Introduccion a las Redes de Petri 9
matriz C de la red es:
t1 t2 t3 t4
C =
1 −1 0 0
−1 1 −3 3
0 0 1 −1
p1
p2
p3
(2.5)
Para esta red, de la matriz C, se infiere entre otras cosas, que al dispararse
la transicion t3 se removeran tres fichas del lugar p2 y se anadira una a p3. En
general, se utiliza la notacion Pre(., t), Post(., t) y C(., t) para referirse a la
columna asociada a la transicion t una de alguna de estas matrices.
Desde el punto de vista matricial, la marcacion de la red se representa con un
vector columna M , cuya dimension es el tamano n del conjunto de lugares P y
que contiene los valores de M(p) para todos los lugares de la red.
2.1.4. Red de Petri Pura
Una red de Petri es pura si se cumple que:
∀p ∈ P, ∀t ∈ T ⇒ Pre(p, t)Post(p, t) = 0 (2.6)
Es decir, una red de Petri es pura si no existe un lugar que sea a la vez entrada
y salida de una misma transicion. En otras palabras, tambien se puede decir que
una red es pura si la interseccion de los lugares de entrada con los de salida
es vacıa. Por ejemplo, las redes de Petri de las Figuras 2.2 y 2.4 no son puras,
mientras que la de la Figura 2.3 es pura.
Matematicamente, una red impura genera matrices Pre y Post que sobrepo-
nen en algun lugar valores distintos de cero (consecuencia directa de la ecuacion
2.6), cosa que no ocurre en una red pura. Esto puede apreciarse en la red pura
de la Figura 2.3 y en sus matrices Pre y Post mostradas en las Ecuaciones 2.2 y
2.3, donde no existe ninguna combinacion (p, t) que produzca entradas en Pre y
en Post distintas de cero simultaneamente. Por ejemplo, las matrices Pre y Post
de la red impura de la Figura 2.4 son:
10 Redes de Petri
p1
t1
t2
p3
t4
t3
p2
[3]
[3]
t5
Figura 2.4: Una Red de Petri no Pura
t1 t2 t3 t4 t5
Pre =
0 1 0 0 0
1 0 3 0 0
0 0 0 1 1
p1
p2
p3
(2.7)
t1 t2 t3 t4 t5
Post =
1 0 0 0 0
0 1 0 3 0
0 0 1 0 1
p1
p2
p3
(2.8)
Donde se hace evidente que Pre(p3, t5)Post(p3, t5) = 1, es decir, que existe al
menos una entrada que es distinta de cero en Pre y que al mismo tiempo lo es
en Post. Por otra parte, en la Figura 2.4 se aprecia que la red no es pura porque
la transicion t5 tiene a p3 como lugar de entrada y salida al mismo tiempo.
2.1.5. Habilitacion de una Transicion
Se dice que una transicion t de una red de Petri esta habilitada si existen
suficientes fichas en las entradas como para satisfacer Pre(., t).
Por ejemplo, en la Figura 2.5, la transicion t1 no esta habilitada. Esto se debe
a que, si bien Pre(p1, t1) = 1 se satisface con M(p1) = 1, Pre(p2, t1) = 1 no lo
hace con M(p2) = 0. Por otro lado, t2 esta habilitada porque Pre(p5, t2) = 1 y
Pre(p6, t2) = 1 se satisfacen ambas con M(p5) = 1 y M(p6) = 1.
2.1 Introduccion a las Redes de Petri 11
p1
p2
p3
p4
p5
p6
p7
p8
t1 t2
Figura 2.5: Habilitacion de una Transicion
Formalmente, una transicion t esta habilitada si y solamente si:
∀p ∈ P,M(p) ≥ Pre(p, t) (2.9)
En este punto, en particular, existen muchas variantes. Es posible, por ejem-
plo, definir los lugares de la red de modo que tengan una capacidad maxima
de fichas. Con esta restriccion adicional, se hace necesario revisar los lugares de
salida, ademas de los de entrada, al momento de determinar si una transicion
esta habilitada o no, todo esto, con el fin de no sobrepasar el maximo de fichas
permitido en un lugar al disparar la transicion. Esta restriccion podrıa escribirse
de la siguiente forma:
∀p ∈ P,M(p) + Post(p, t) ≤Max(p) (2.10)
Donde Max : P → N, y Max(p) representa la maxima cantidad de fichas
permitidas en el lugar p.
2.1.6. Disparo de una Transicion
Si una transicion t esta habilitada para una determinada marcacion M , es
posible obtener una nueva marcacion M ′ por medio del disparo de t, utilizando
la ecuacion:
∀p ∈ P,M ′(p) = M(p)− Pre(p, t) + Post(p, t) (2.11)
12 Redes de Petri
o bien de forma vectorial:
M ′ = M − Pre(., t) + Post(., t) = M + C(., t) (2.12)
Cuando una transicion es disparada, se remueve una determinada cantidad de
fichas de cada lugar de entrada segun los pesos de los arcos que conectan dichos
lugares con la transicion. De igual forma, segun los pesos de los arcos que salen
de la transicion, se anaden fichas a todos los lugares de salida.
p1
p2
p3
p4
p1
p2
p3
p4
t1 t1
Figura 2.6: Disparo de una Transicion
La Figura 2.6, muestra la transicion t1 y sus lugares asociados antes y despues
del disparo de la misma. En este caso, ningun arco tiene un peso mayor que uno,
por lo tanto, solo se elimina una ficha de cada lugar de entrada y se agrega una
a cada lugar de salida.
2.1.7. Conflicto Estructural y Efectivo
Cuando dos transiciones comparten un recurso (ver Figura 2.7), se produce un
conflicto. Existen dos tipos de conflictos, el primero se llama conflicto estructural,
y el segundo, conflicto efectivo. Un conflicto estructural se presenta cuando un
lugar es compartido (recurso compartido) por dos o mas transiciones. Un conflicto
efectivo se presenta en el caso de que un lugar este compartido por dos transiciones
y ademas estas esten habilitadas.
Dos transiciones t1 y t2 estan en conflicto estructural (ver Figura 2.7-a) si
tienen un lugar de entrada en comun:
2.1 Introduccion a las Redes de Petri 13
a) b)
p1
p2
p3
p4
p5
p1
p2
p3
p4
p5
t1
t2
t1
t2
Figura 2.7: Conflicto: a) Estructural, b) Efectivo
∃p ∈ P, Pre(p, t1)Pre(p, t2) 6= 0 (2.13)
Por otro lado, se dice que dos transiciones t1 y t2 estan en conflicto efectivo
para una marcacion M si estan en conflicto estructural, es decir, se cumple la
ecuacion 2.13, y ademas estan habilitadas (ver Figura 2.7-b).
2.1.8. Secuencia de Disparo
Dada una red de Petri, es posible llevarla de una marcacion M0 a una marca-
cion M2 por medio de una serie de disparos de transiciones. Esto puede anotarse,
por ejemplo, de la siguiente forma:
t1,t2M0 −→ M2
(2.14)
La secuencia de transiciones que es necesario disparar para llevar una red de
Petri de una marcacion inicialMo a una marcacion finalMf , es llamada secuencia
de disparo y se denota s = t1t2...tn.
14 Redes de Petri
2.1.9. Conjunto de Marcaciones Accesibles
El conjunto de marcaciones accesibles de una red de Petri, es el conjunto de
marcaciones que pueden ser alcanzadas por la red a partir de una marcacion
inicial, por medio de una secuencia de disparos.
120
300
030
210
001
t1
t2
t1 t2
t1 t2
t3
t4
Figura 2.8: Marcaciones Accesibles de una Red de Petri
Este conjunto (si es finito) se puede representar por medio de un grafo. La
Figura 2.8 representa el conjunto de marcaciones accesibles para la red de la
Figura 2.3. Es importante decir, que el conjunto de marcaciones accesibles (y su
grafo asociado) es ademas la maquina de estado equivalente a la red de Petri que
lo origina. Respecto a este punto, en la seccion 2.3 se hablara de la relacion que
existe entre las maquinas de estado y las redes de Petri, mostrando las ventajas
y desventajas de ambas estructuras.
2.1.10. Redes de Petri Acotadas
Dado un k ∈ N, entonces una red de Petri R se dice que es k-acotada si y solo
si:
2.2 Redes de Petri con Arcos Inhibidores 15
∀M ∈ R y ∀P ∈ P entonces M(p) ≤ k (2.15)
Es decir, para todas las marcaciones alcanzables por la red, ningun lugar
tendra mas de k fichas.
Si se analiza el grafo de marcaciones accesibles de la Figura 2.8, es evidente que
la maxima cantidad de fichas contenidas por un lugar para todas las marcaciones
es tres. Por esta razon, se dice que la red de la Figura 2.3 es 3-acotada. Por otra
parte, si una red de Petri no es k-acotada, entonces existe al menos un lugar que
puede llegar a tener un numero infinito de fichas, y debido a esto, entonces la red
tendra un numero infinito de estados.
Un ejemplo de una red de Petri no acotada se muestra en la Figura 2.10, y en
su grafo de marcaciones accesibles en la Figura 2.11, donde se aprecia que la red
evoluciona desde su estado inicial por un numero infinito de marcaciones.
2.2. Redes de Petri con Arcos Inhibidores
En general, se han propuesto muchos elementos agregados a las redes de Petri,
con el fin de ampliar su funcionalidad (ver seccion 2.4) y permitir que las mismas
sean utiles y brinden soporte para una gran cantidad de aplicaciones. Uno de
estos elementos anadidos son los arcos inhibidores. En la Figura 2.9 se muestra
un arco de este tipo que parte del lugar p3 y se conecta por el otro extremo con
la transicion t1.
El objetivo basico de un arco inhibidor es habilitar una transicion si la pre-
condicion asociada al mismo (o post-condicion) no esta habilitada. En otras pa-
labras, una transicion asociada a un arco inhibidor estara habilitada si el lugar al
que esta asociado el arco esta deshabilitado y viceversa. Es decir, desde el punto
de vista de la habilitacion de una transicion, el arco inhibidor cumple un papel
opuesto al de un arco convencional.
Sin embargo, desde el punto de vista funcional, cuando una transicion se dis-
para, los arcos inhibidores no restan ni suman fichas de los lugares de origen
16 Redes de Petri
p4
p1
t1
p5
p2p3
p4
p1
t1
p5
p2p3
t2 t2
b)a)
Figura 2.9: Efecto de un Arco Inhibidor: a) t1 Deshabilitada, b) t1 Habilitada
o destino (operacion que no tendrıa sentido dada la naturaleza de este tipo de
arcos). Es decir, los arcos inhibidores cumplen una funcion al momento de deter-
minar si una transicion esta o no habilitada, pero no cumplen ningun papel al
momento de ejecutar la transicion.
Como ejemplo, en la Figura 2.9 a), la transicion t1 esta deshabilitada, porque
si bien p1 contiene fichas, p3 tambien las contiene, y el arco inhibidor que va
desde p3 a t1 no permite que t1 este habilitada. Luego, en la Figura 2.9 b), t1
esta habilitada porque p1 contiene fichas y p3 no contiene.
2.3. Maquinas de Estado y Redes de Petri
La relacion que existe entre las redes de Petri y las maquinas de estado es
bastante estrecha, sobre todo, porque ambas son herramientas utilizadas para
modelar sistemas de eventos discretos.
En general, si la red de Petri es k-acotada, entonces es posible encontrar una
maquina de estados finita equivalente a la red. Luego, si el numero de estados
representados por una red es finito, entonces el grafo de marcaciones accesibles
sera una maquina de estado funcionalmente similar a la red de Petri.
Por ejemplo, el grafo de marcaciones accesibles de la Figura 2.8 es la maquina
de estados equivalente a la red de Petri de la Figura 2.3. En dicho caso, el numero
2.4 Redes de Petri de Alto Nivel 17
p2 p3
p1
t1t2 t3
Figura 2.10: Red de Petri con un Numero Infinito de Estados
de nodos de la maquina de estados es ligeramente menor que los de su red de
Petri equivalente, pero esto no siempre es ası. De hecho, para la mayorıa de las
redes de Petri, la maquina de estado es mucho mas compleja que la red misma.
Esta “explosion de estados” se debe a que una maquina de estados utiliza un
nodo para cada estado en el que se puede encontrar el sistema, mientras que en
una red de Petri, el estado se representa mediante una combinacion de fichas en
los distintos lugares.
Por otro lado, si la red de Petri no es k-acotada (ver Figura 2.10), no existe
una maquina de estados finita equivalente a la red, ya que el numero de esta-
dos representados en la red es infinito (Figura 2.11). No es posible utilizar una
maquina de estados finita para representar un sistema con un numero infinito
de estados (apenas hay algunas tecnicas para aproximarse), pero si es posible
representar un sistema de este tipo utilizando redes de Petri.
2.4. Redes de Petri de Alto Nivel
En general, en algun momento, a las redes de Petri clasicas les ocurrio lo mismo
que a las maquinas de estado; se quedaron pequenas al momento de solucionar
ciertos problemas de gran complejidad. En algunos casos, ciertos sistemas no
18 Redes de Petri
1
10
012
11
1
022
0
11
01
01
1
0 1
02
t1
t2 t3t1 t1
t2 t3
201
20
1
t1t1
031
013
t3 t2
t1
... ... ... ... ... ...t2 t3 t2 t3 t2 t3
Figura 2.11: Marcaciones Accesibles (infinitas) de una red de Petri
podıan ser modelados mediante los componentes tradicionales de las redes de
Petri (transiciones, lugares y aristas simples), mientras que en otros casos, si bien
los sistemas si podıan ser modelados, la complejidad de la red de Petri resultante
la volvıa en algun momento inmanejable.
A causa de los problemas que se presentaban con las redes de Petri tradiciona-
les, comenzaron a surgir algunas modificaciones, variantes y componentes nuevos
que permitıan atacar mas facilmente algunos sistemas que resultaban difıciles y
hasta imposibles de manejar con las redes convencionales. Debido a esto, nacie-
ron toda una nueva serie de redes de Petri que tenıan en cuenta factores como
el tiempo, probabilidades y estadıstica, realizaban operaciones complejas con las
fichas (que tambien representaban datos complejos) y que, en general, anadıan
toda una serie de elementos, componentes y comportamientos nuevos a las redes
de Petri tradicionales. Fue entonces cuando entraron en escena conceptos como
los de Redes de Petri Coloreadas, Redes de Petri Estocasticas y Redes de Pe-
tri Temporizadas, entre otras. Con el tiempo, todos estos nuevos tipos de redes
fueron agrupados y vistos bajo el nombre de Redes de Petri de Alto Nivel.
2.4 Redes de Petri de Alto Nivel 19
v1
v2
v3
v1< v
2
v2
v1
v3
( ),
= −
p1
p2
p3
1
3
4
2
t1
Figura 2.12: Red de Petri de Alto Nivel
Las redes de Petri de alto nivel fueron propuestas en 1980, debido a que cuando
se trata de modelar sistemas complejos con redes de Petri tradicionales, estos
sufren una explosion en tamano que hace que el modelo sea difıcil de manejar
(fenomeno similar al que ocurre con las maquinas de estado). En las redes de
Petri tradicionales, las fichas representan objetos simples del mismo tipo y con un
mismo valor. En las redes de alto nivel, las fichas representan una gran variedad de
tipos de datos como booleanos, enteros, reales, arreglos, registros, etc. Ademas de
los tipos de fichas complejas, las redes de alto nivel incluyen reglas para manipular
la informacion contenida en las fichas (Robert Esser, 1996).
La red de la Figura 2.12 muestra una red de alto nivel que utiliza fichas de
tipo entero y tiene una transicion con una funcion guarda G(t) = v1 ≤ v2 y una
funcion de salida F (t) = v2 − v1. La funcion guarda es una restriccion adicional
que debe cumplirse para que la transicion este habilitada, mientras que, la funcion
de salida se encarga de generar las fichas adecuadas en los lugares de salida de la
transicion.
Si bien las redes de alto nivel son conceptualmente mucho mas complejas que
las redes de Petri tradicionales, esta complejidad adicional se ve compensada por
el hecho de que es posible modelar sistemas mas complejos con mayor facilidad.
Algunos autores (Gile & DiCesare, *) comparan la evolucion de los distintos tipos
de redes de Petri con la de los lenguajes de programacion (ver Figura 2.13). Sobre
este punto, afirman que las maquinas de estados son comparables con los lenguajes
de ensamblador, es decir, si bien son eficientes, las posibilidades de desarrollo
20 Redes de Petri
Redes de Petri de Alto Nivel
Redes de Petri
Maquinas de Estado
Herramientas de Modelado
Lenguajes Orientados a Objetos
C++, Java, Smalltalk, etc
Lenguajes de Alto Nivel
C, Pascal, Fortran, etc
Lenguajes de Ensamblador
Lenguajes de Programacion
Abs
trac
cion
Men
os E
rror
es
Efic
ienc
ia
Figura 2.13: Comparacion Entre Redes de Petri y Lenguajes de Programacion
son muy limitadas. Por otro lado, las redes de alto nivel son comparables con
los lenguajes de alto nivel, en donde la eficiencia es un poco menor que en los
lenguajes de bajo nivel, pero las posibilidades de desarrollo son mucho mayores.
Capıtulo 3
Modelo Ampliado de Redes de
Petri
En el capıtulo anterior se mostraron las ventajas de las redes de Petri, dis-
cutiendo inicialmente sobre redes tradicionales y haciendo luego referencia a la
evolucion de las mismas en otras mas complejas y flexibles. En general, uno de los
requisitos del software desarrollado en este proyecto consiste en brindar un mode-
lo facilmente expandible que permita con poco esfuerzo implantar redes de Petri
clasicas y de alto nivel (ver seccion 4.1), es decir, la idea es crear una plataforma
que permita en un futuro manejar una amplia variedad de redes de Petri. De
forma que, el presente capıtulo pretende hacer un recorrido por los componentes
ya implantados en el motor, y ademas de eso, exponer algunas de las dificulta-
des encontradas desde el punto de vista del diseno del software al momento de
desarrollar los distintos componentes de una red de Petri (transiciones, lugares y
aristas).
3.1. Eventos
Los eventos son los estımulos originados por el mundo exterior que producen
cambios en una red de Petri. Una red cambia de estado y evoluciona en funcion
22 Modelo Ampliado de Redes de Petri
de los eventos que reciba y del orden en que sean procesados. Para que un evento
produzca un cambio de estado en una red de Petri, debe existir una transicion
habilitada asociada al mismo. En la siguiente seccion se detallan las condiciones
que deben cumplirse bajo el modelo ampliado de redes de Petri para que una
transicion este habilitada.
Los eventos representan sucesos del mundo exterior. Un evento puede repre-
sentar sucesos tan distintos como el inicio de un proceso de produccion, un usuario
pulsando un enlace o un boton de una pagina Web, la apertura de una valvula o
la averıa de una maquina, entre otros. Algunos eventos tienen asociadas porciones
de informacion que son necesarias para describirlos.
Por ejemplo, la peticion de inicio de un proceso de produccion tendra asociada
la cantidad de producto que se desea obtener. El evento generado por el usuario
de la pagina Web puede tener asociados los parametros de la peticion HTTP, de
modo que una red de Petri pueda decidir a que pagina enviarlo como resultado
de la peticion. La averıa de una maquina puede tener asociada la direccion fısica
de la misma, para que esta pueda ser incluida en un reporte de fallas y que el
departamento tecnico sepa que maquina debe reparar.
El motor de ejecucion acepta eventos que vengan acompanados por parame-
tros, siendo el comportamiento por defecto transferir y hacer que los componentes
involucrados con un evento determinado (transiciones, aristas y lugares) tengan
conocimiento de dichos parametros.
Por otra parte, un evento debe poder ejecutarse de forma atomica, es decir,
sin interrupcion desde que comienza hasta que termina. Esto es imprescindible
para mantener la integridad de la red de Petri y de la informacion asociada a
la misma. Una red de Petri nunca puede estar ejecutando dos eventos de forma
simultanea.
3.2 Transiciones 23
3.2. Transiciones
Las transiciones son los componentes asociados a la dinamica de la red de
Petri. Representan la reaccion de la red frente a los eventos del mundo exterior.
Las transiciones estan asociadas a eventos. Cada transicion puede estar aso-
ciada solo a un unico evento, pero un evento puede estar asociado a muchas
transiciones dentro de una misma red. Una transicion depende de dos factores
para que pueda dispararse, el primero, que llegue el evento al cual esta asociada,
y el segundo que este habilitada. Una transicion esta habilitada si puede ejecutar
con exito todas sus aristas asociadas. Las aristas entrantes estan asociadas con las
pre-condiciones de la transicion, mientras que las aristas salientes estan asociadas
con las post-condiciones.
2.1.− Cada arista consultacon su lugar asociado
3.1.− Cada arista consultacon su lugar asociado
4.− Si todas las aristas / lugares entrantesy salientes estan habilitados, latransicion se dispara
1.− Llega un evento
a las aristas salientes3.− La transicion consulta
p2
t1e1
p4 p5
p1
p3
0 0 0
0 0
01
01
01
01
01
2.− La transicion consultaa las aristas entrantes
Figura 3.1: Disparo de una Transicion
En general, un evento asociado a una transicion es procesado por esta en
cuatro pasos:
1. Llega el evento a la transicion.
24 Modelo Ampliado de Redes de Petri
2. La transicion ejecuta todas sus aristas entrantes y verifica que esten habi-
litadas.
3. La transicion ejecuta todas sus aristas salientes y verifica que esten habili-
tadas.
4. Finalmente, si todas las aristas entrantes y salientes estan habilitadas, la
transicion se dispara.
Una transicion determina si esta o no habilitada, consultando a todas las
aristas entrantes y salientes. Si todas y cada una de estas aristas se encuentran
habilitadas, entonces la transicion esta habilitada y se disparara al momento de
llegar el evento asociado a la misma. Por otra parte, las aristas determinan si
estan o no habilitadas consultando a su lugar asociado.
3.2.1. Problemas de Conflicto
En el modelo clasico de redes de Petri se asume que las transiciones responden
a los eventos de forma inmediata. De esta manera, la ejecucion de una transicion
(verificar pre-condiciones, post-condiciones y disparar la transicion) es en teorıa,
instantanea. Como consecuencia de la suposicion anterior, entre otras cosas, se
asume que dos eventos no se ejecutaran nunca de forma simultanea. Al no existir
simultaneidad en la ejecucion de dos eventos, no es posible que se produzca un
problema de conflicto (o concurrencia), ya que dos transiciones nunca competiran
por el acceso a un mismo lugar. Sin embargo, a nivel practico, no es posible
ejecutar una transicion instantaneamente, ası como tampoco se puede evitar que
un evento llegue a la red de Petri mientras que otro se esta ejecutando. Tales
limitaciones practicas, tarde o temprano, generan problemas de concurrencia que
deben ser manejados por el motor de ejecucion.
En el caso de la Figura 3.2, dos transiciones (asociadas a eventos distintos)
poseen al menos un lugar en comun. Cuando llega un evento e1 a la red, la
transicion t1 se encuentra habilitada y por lo tanto dispara. Pero en ese instante,
3.2 Transiciones 25
Lugares Compartidos
e1 e2t2t1
p1 p3
p2
p5
p6p40
1 1 1
0 010 0
101
01
01
01
Figura 3.2: Conflicto
entra a la red un evento e2, antes de que la ejecucion de t1 logre descontar la
ficha del lugar p2. Desde la optica del segundo evento, su transicion asociada t2
esta habilitada y debe dispararse, pero eso es un error, ya que la ficha de p2
esta comprometida con la ejecucion de la primera transicion y no deberıa estar
disponible para la segunda.
Es por esto que el motor debe garantizar que la ejecucion de un evento trans-
curra de forma atomica, sin interrupciones desde que comienza hasta que termina.
En otras palabras, un evento esta asociado a una serie de transiciones, y estas a
una serie de lugares y aristas. Pero muchos lugares son compartidos por varias
transiciones, asociadas a su vez con otros tipos de eventos. De esta forma, es ne-
cesario que la ejecucion de un evento y sus transiciones asociadas ocurra sin que
otro evento asociado a otras transiciones interfiera, siempre y cuando comparta
lugares con el primer evento.
Otro posible problema de concurrencia se puede presentar cuando dos o mas
transiciones asociadas a un mismo evento comparten lugares comunes. Si bien el
caso anterior se puede resolver (de una forma facil pero ineficiente) ejecutando
26 Modelo Ampliado de Redes de Petri
un evento a la vez, en este caso, tal solucion no es posible, ya que el problema de
concurrencia se produce dentro del contexto de ejecucion de un mismo evento.
Existen dos posibles soluciones (en lo absoluto mutuamente excluyentes) que
permiten resolver el problema de concurrencia dentro del contexto de ejecucion
de un mismo evento. La primera, contempla que las transiciones asociadas a un
mismo evento se marquen al momento del diseno de la red, de forma que el
motor conozca explıcitamente el orden en que deben ejecutarse. De esta forma,
la transicion con mas precedencia se ejecutara primero y tendra prioridad sobre
sus recursos asociados.
Otra solucion consiste en determinar, antes de ejecutar un evento, cuales tran-
siciones estan habilitadas y cuales no lo estan. Esta operacion de comprobacion
debe poder determinar el estado de una transicion (habilitada o no) sin tener que
ejecutarla y sin modificar sus aristas y lugares asociados. De esta forma, es posible
obtener una lista de transiciones habilitadas y transiciones no habilitadas para un
determinado evento en un determinado momento. Como paso siguiente, se deben
ejecutar todas las transiciones habilitadas en bloque, como en una transaccion.
Si alguna de las transiciones falla en su ejecucion es porque se presento un pro-
blema de concurrencia. En este caso, el error debe reportarse y la ejecucion de
las transiciones debe abortar, restaurando la red al estado anterior a la llegada
del evento.
Tal situacion se podrıa ver en la Figura 3.2 si se cambia el evento asociado
a t2 de e2 a e1. En ese caso, el motor no puede determinar que transicion debe
ejecutar primero, si t1 o t2. Ambas transiciones no pueden ejecutarse, si se ejecuta
t1 primero, esta consumira la ficha de p2 y dejara a t2 deshabilitada. Este proceso
hace que la red se vuelva difıcil de predecir (por no decir incoherente) en un
momento dado, ya que una transicion que inicialmente podıa dispararse, fallo al
momento de ejecutarse.
En este caso, una solucion podrıa ser especificar explıcitamente una preceden-
cia para resolver el orden de ejecucion de las transiciones. Es decir, se le puede
asignar a t1 una precedencia mayor que a t2, de modo que el motor sabe que debe
3.2 Transiciones 27
ejecutar t1 primero y luego, si quedan recursos, a t2.
Otra forma, utilizando el modelo de transacciones (donde todos los compo-
nentes se ejecutan adecuadamente o no se ejecuta ninguno), serıa no tomando
en cuenta el orden de ejecucion de las transiciones. De esta manera, la primera
transicion se ejecutarıa correctamente, y al fallar la segunda, toda la ejecucion
del evento se abortarıa y la red se devolverıa al estado anterior a la llegada del
mismo.
3.2.2. Transicion Simple
Esta es la transicion mas simple que existe y es en general la base para todas
las demas. Cuando llega un evento asociado a una transicion, esta sigue los pasos
de la Figura 3.1. Su comportamiento al momento de dispararse es no hacer nada.
e1
t1
Figura 3.3: Transicion Simple
3.2.3. Transicion Generadora de Eventos
La Transicion Generadora de Eventos sigue el comportamiento basico de la
Figura 3.1, pero al dispararse genera un evento dirigido a la red de Petri que la
contiene, a alguna otra arbitraria especificada al disenar la red, o a alguna especi-
ficada en los parametros del evento inicial que disparo la transicion. Los eventos
generados por este tipo de transicion son colocados en una cola y procesados des-
pues de que se termina con el evento en curso, pero antes de ejecutar cualquier
otro evento proveniente del mundo exterior.
e1
t1
Figura 3.4: Transicion Generadora de Eventos
28 Modelo Ampliado de Redes de Petri
Es necesario utilizar con extremo cuidado este tipo de transiciones, ya que no
es difıcil imaginarse un caso en el que se pueda caer en un lazo infinito.
1
01
0
01
e1 t1 t2 e2
p1
p2
Figura 3.5: Situacion de Lazo Infinito
La Figura 3.5 muestra una situacion en la que si t1 genera un e2, y t2 genera
un e1, entonces al llegar e1, la red cae en un estado de lazo infinito. En general, no
existe una forma sencilla de detectar tales lazos en la implementacion del motor,
ası que, es necesario tener estos casos en cuenta al disenar las redes.
3.2.4. Transicion Asociada a Codigo Java
Una transicion de este tipo ejecutara al dispararse un metodo de una clase
JavaTMdefinida en el momento de disenar la red de Petri. Es responsabilidad del
disenador que la clase y el metodo sean validos y esten presentes en el servidor
al momento de dispararse la transicion. La clase y el metodo son instanciados e
invocados dinamicamente por el motor utilizando reflexion de JavaTM. El motor
de ejecucion debe reportar cualquier error en tiempo de ejecucion que pueda
generar una transicion de este tipo.
3.3 Lugares 29
e1
t1
Figura 3.6: Transicion Asociada a Codigo Java
3.3. Lugares
Los lugares son los componentes de una red de Petri asociados al estado de la
red.
El estado de una red de Petri, en un instante determinado, viene dado por la
marcacion de la red. En el caso de una red de Petri clasica, que solo tiene lugares
con fichas, la marcacion de la red viene dada por el numero de fichas que estan
presentes en cada uno de los lugares de la red. En el caso del modelo ampliado de
redes de Petri, la situacion se complica porque la red no solo esta compuesta por
lugares con fichas. La red puede tener lugares complejos en los que no siempre
es facil y claro ver cual es la marcacion del lugar. Por ejemplo, un lugar puede
representar una consulta a una base de datos, siendo la marcacion 1 si la consulta
no es vacıa y 0 si la consulta no genera resultados.
Ademas, las redes de Petri clasicas son grafos bipartitos no ponderados, es
decir, que lo unico que importa de una arista es de donde viene y a donde va.
Sin embargo, el modelo ampliado aquı propuesto, sugiere que las aristas tengan
una funcion mas protagonica en la ejecucion de la red, cumpliendo un papel en
la evaluacion de la habilitacion de un lugar. Por ejemplo, en el caso de un lugar
con fichas coloreadas, la arista que lo conecta con su transicion asociada puede
especificar el numero de fichas de cada color que se deben desplazar para que el
lugar este habilitado.
3.3.1. Marcacion de un Lugar
El estado de un lugar viene representado por su marcacion. En el caso de las
redes de Petri clasicas, la marcacion de un lugar es el numero de fichas presentes
en dicho lugar. Sin embargo, el modelo ampliado complica un poco las cosas, ya
30 Modelo Ampliado de Redes de Petri
que ahora es posible tener un sin fin de lugares de distintos tipos interactuando
juntos en una misma red, de modo que ya no existe una sola forma de representar
la marcacion de un lugar. En general, la marcacion de un lugar, sirve en el modelo
clasico de redes de Petri para determinar si el lugar esta o no habilitado, pero en
el modelo extendido se puede dar el caso de que, sin la presencia de un evento
(con sus respectivos parametros), no sea posible determinar si un lugar esta o no
habilitado. Ese es el caso de los Lugares Asociados a Codigo JavaTM, donde la
habilitacion o no del lugar depende del codigo que se ejecute y de los parametros
asociados al evento.
Por las razones expuestas anteriormente, el modelo ampliado define la mar-
cacion de un lugar como un elemento particular al tipo de lugar. Es decir, para
un lugar de fichas, la marcacion sera el numero de fichas presentes (como en el
modelo clasico). Para un lugar con fichas coloreadas, la marcacion sera una tabla
cuya clave es el color y que tiene por valor en cada entrada el numero de fichas
presentes en el lugar para el color especificado. Un ejemplo aun mas dramatico es
el de la marcacion de un lugar JavaTM, en el que solo existen tres posibilidades a
saber: no habilitado, habilitado e indefinido. En general, un lugar JavaTMdeberıa
hacer el mejor esfuerzo para determinar su estado, pero en casos en los que esto
no sea posible, debido a que no estan presentes los parametros de un evento,
entonces la marcacion del lugar es indefinida, es decir, no es posible determinar
si esta habilitado o no.
3.3.2. Lugar de Fichas
Los Lugares de Fichas cumplen la funcion clasica de los lugares en las redes de
Petri. Son nodos que contienen fichas que son eliminadas o agregadas a medida
que se van disparando transiciones en la red. En teorıa, un lugar de este tipo
esta habilitado si contiene al menos una ficha. Sin embargo, el modelo ampliado
permite que las aristas jueguen un papel al momento de determinar si un lugar
esta o no habilitado. Mas adelante, se vera que existe una combinacion transicion-
arista-lugar que permite emular el comportamiento clasico de un lugar con fichas.
3.3 Lugares 31
0
1
0
p1
Figura 3.7: Lugar de Fichas
Adicionalmente, esta clase de lugares permite acotar la mınima y maxima
cantidad de fichas que son validas para que el lugar este habilitado. Cualquier
intento de sustraer fichas por debajo del mınimo o agregar por arriba del maximo,
generara como resultado que el lugar fallara en su ejecucion y, por lo tanto, no
estara habilitado.
3.3.3. Lugar de Fichas Coloreadas
Los Lugares de Fichas Coloreadas representan una forma comoda de agrupar
varios lugares de fichas en un solo sitio. Un lugar de este tipo posee un conjunto
de colores, y por cada color existe una determinada cantidad de fichas.
p1
Figura 3.8: Lugar de Fichas Coloreadas
3.3.4. Lugar Asociada a Codigo Java
Un lugar JavaTMdetermina si esta o no habilitado ejecutando un programa
JavaTMespecificado al momento del diseno de la red. Cuando al lugar se le pre-
gunta si esta o no habilitado se ejecuta un metodo que debe retornar verdadero
si el lugar esta habilitado o falso si no lo esta. Ademas, es necesario especificar
un metodo que ejecutara en sı el lugar.
32 Modelo Ampliado de Redes de Petri
p1
Figura 3.9: Lugar Asociado a Codigo Java
Los lugares JavaTMpueden ser utilizados en casos en los que, por ejemplo, la
habilitacion de un lugar depende de una consulta a una base de datos o a algun
otro recurso similar. Por otra parte, la ejecucion de un lugar de este tipo puede
representar un cambio en algun registro en una base de datos llevado a cabo por
el metodo invocado a la hora de ejecutar el componente.
3.4. Aristas
Las aristas en las redes de Petri clasicas cumplen la funcion de enlazar las
transiciones con los lugares. Sin embargo, en el modelo ampliado de redes de Petri,
las aristas juegan un papel mas activo. En general, una transicion esta habilitada
si todas sus aristas entrantes o salientes estan habilitadas. Esto es coherente con
la definicion de redes de Petri del capıtulo anterior, donde se especifica que una
arista determina si una transicion esta o no habilitada dependiendo del numero de
fichas que se desean eliminar (o agregar) de un lugar. Las aristas ademas pueden
funcionar como arcos inhibitorios. En tal situacion, una arista estara habilitada
si su lugar asociado no lo esta (segun los criterios de la arista y el lugar), pero
sin embargo, al momento de su ejecucion, la arista debe abstenerse de realizar
cambios en la red de Petri (ver seccion 2.2).
3.4.1. Arista de Fichas
Una arista de fichas puede unirse por uno de sus extremos con una transicion
de cualquier tipo, y por el otro, con un Lugar de Fichas. Esta arista tiene asociado
un peso, que representa el numero de fichas que se anadiran o removeran del lugar
3.4 Aristas 33
con el que conecta segun sea el caso. Si la arista va de un lugar a una transicion,
entonces las fichas se removeran del lugar, si va de una transicion a un lugar,
entonces se anadiran al lugar.
3.4.2. Arista de Fichas Coloreadas
Una Arista de Fichas Coloreadas cumple la misma funcion que la Arista de
Fichas, pero en lugar de manejar una unica ficha, maneja multiples fichas de
distintos colores. Esta arista tiene asociados n pesos, donde n es el numero de
colores presentes en el lugar con el que esta asociada. Los pesos definen el numero
de fichas de un color determinado que seran restadas o sumadas al lugar asociado
en caso de que la arista sea ejecutada.
3.4.3. Arista Simple
La Arista Simple tiene como funcion unir transiciones con lugares que solo
tienen dos posibles estados: habilitados o no habilitados. En general, sirven para
unir transiciones a lugares JavaTM y cualquier otro lugar que tenga solo estos
dos estados. Sin embargo, desde el punto de vista practico, una arista simple
debe tambien poder manejar lugares cuyo estado sea indefinido, esto permite
determinar el estado de una transicion (habilitado, no habilitado o indefinido),
en caso de que al motor le sean consultados dichos estados sobre una red en
particular.
Capıtulo 4
Arquitectura del Sistema
4.1. Requerimientos
A lo largo de la literatura consultada se pudo verificar que a partir del con-
cepto simple de redes de Petri clasicas evolucionan una gran cantidad de redes
de distintos tipos. En general, el software que se encontro en el mercado, algunos
productos de distribucion gratuita y algunas conclusiones extraidas de (Harald
Storrle, 1998), se enfocan en la simulacion de redes de Petri clasicas, y no aprove-
chan la posibilidad de conectar las redes con otro software que pueda utilizarlas.
Sin embargo, no se encontro ninguna implementacion de redes de Petri de alto ni-
vel o redes coloreadas. Tampoco se pudo hallar una implementacion de un motor
de ejecucion que pueda ser utilizado como repositorio de redes de Petri, donde las
mismas corran y evolucionen (en un ambiente de produccion) en funcion de los
eventos que reciben del exterior, de modo que sea posible en un momento dado
obtener informacion util sobre el estado de una red.
Este fue el panorama que incentivo el desarrollo de esta tesis. No es la intencion
de este proyecto aportar otro software que simule redes de Petri clasicas, o cubrir
la carencia de simuladores de redes de Petri de alto nivel o coloreadas, aun cuando
al final este proyecto tambien pueda ser utilizado para atacar cualquiera de los
puntos mencionados anteriormente. De hecho, la idea fundamental de esta tesis
36 Arquitectura del Sistema
no es simular redes de Petri, es ejecutarlas. La diferencia radica en que al simular
una red de Petri solo se esta validando el modelo, es decir, se determinan sus
propiedades, comportamiento, se detectan abrazos mortales, etc. Al ejecutar la
red, esta se pone a correr en paralelo con el sistema modelado (algunas veces ella
misma es el sistema) de modo que es posible tener una idea del estado de dicho
sistema. Ademas, hay aplicaciones en las que se desean coordinar procesos, y en
estos casos la red debe correr a la par del sistema.
En general, la intencion de este proyecto es definir una arquitectura versatil
(basada en el concepto de componentes) que permita implementar y ejecutar
cualquier tipo de redes de Petri. Si alguna aplicacion en particular necesita un
lugar en particular, este debe poder programarse e integrarse al motor de una
forma sencilla y practica.
Por otra parte, muchos procesos y sistemas que generalmente corren de forma
distribuida, se pueden modelar y coordinar utilizando redes de Petri. Esto significa
que es necesario tener el motor de ejecucion corriendo como un servicio en alguna
maquina, de modo que los clientes puedan registrar y ejecutar redes de Petri de
forma remota. Ademas, muchos proyectos de software pueden aprovechar para
modelar y seguirle la pista a ciertos procesos utilizando redes de Petri pero no
como servicio, sino como librerıa.
De modo, que las premisas de diseno y los requerimientos del software resultan
ser:
1. Debe ser posible agregar componentes para poder crear luego redes com-
plejas.
2. Es necesario que corra como un servicio por si mismo (standalone).
3. Debe poder correr como librerıa para ser utilizado localmente desde una
aplicacion.
4. Alta portabilidad.
4.2 Arquitectura General del Sistema 37
4.2. Arquitectura General del Sistema
Fundamentalmente, el sistema esta compuesto por cinco actores: El motor de
ejecucion, la interfaz remota, la interfaz local, el editor y los clientes. Estos ele-
mentos y las relaciones entre los mismos se muestran de forma general en la Figura
4.1. Las lıneas punteadas representan comunicacion entre los modulos de forma
remota (una red de area local, por ejemplo), mientras que las lıneas continuas
representan comunicacion local dentro de un mismo espacio de direcciones.
Cliente
Editor
BD
BD
Motor
Motor
Interfaz Local(libreria)
Interfaz Remota(servicio)
Redes de PetriSerializadas
Figura 4.1: Arquitectura General del Sistema
4.2.1. El Motor de Ejecucion
El motor de ejecucion se encarga de manejar todo lo relacionado con las redes
de Petri. Brinda la interfaz y la implementacion necesaria para administrar las
redes, estas operaciones se pueden resumir de la siguiente forma:
Registrar nuevas redes de Petri en el motor y ponerlas en ejecucion.
Guardar en la base de datos una red registrada cuando no es necesario
tenerla en memoria.
Recuperar una red de la base de datos cuando sea necesario realizar una
operacion sobre la misma.
38 Arquitectura del Sistema
Suspender temporalmente la ejecucion de una red de Petri.
Resumir la ejecucion de una red previamente suspendida.
Eliminar redes de Petri del motor.
Consultar el estado de una red de Petri (marcacion y transiciones habilita-
das).
Listar las redes que estan corriendo en el motor y su estado de ejecucion
(corriendo o suspendidas).
Manejar los eventos que llegan al sistema y ejecutarlos en la red adecuada.
4.2.2. Ciclo de Vida de una Red de Petri
Utilizando como base las operaciones de la lista anterior, es posible definir el
ciclo de vida para una red de Petri en el motor (ver Figura 4.2). Una red no existe
en el motor hasta que es registrada, momento en el cual pasa automaticamente al
estado en ejecucion. Inmediatamente la red es almacenada en la base de datos (de
modo que si ocurre una falla en el servidor la informacion no se pierde) pero se
mantiene una copia en memoria para atender futuras peticiones. Una red responde
a eventos solo si se encuentra en ejecucion, de modo que si la red esta en cualquier
otro estado los eventos son ignorados (suspendida) o es necesario hacer que la red
cambie de estado primero antes de que pueda procesar un evento (pasiva).
Sin embargo, es posible que la red no sea utilizada con frecuencia y mante-
nerla en memoria represente un desperdicio de recursos, ası que despues de cierto
tiempo de inactividad la red es eliminada de la memoria y pasa al estado pasiva.
Por otro lado, si en algun momento llega un evento o se hace una peticion de
administracion dirigida a una red que esta en la base de datos pero no en memo-
ria, el motor debe recuperar la red de la base de datos y subirla a memoria para
poder cumplir con la peticion (menos si la peticion es de eliminacion, caso en el
cual la red es simplemente eliminada de la base de datos).
4.2 Arquitectura General del Sistema 39
No Existe
En Ejecucion Pasiva (BD)
Suspendida
ejecucion deevento
eliminacion
no en uso
requerida
requerida
no en uso
suspender resumir
registro
Figura 4.2: Ciclo de Vida de una Red en el Motor
Ademas, si una red esta en ejecucion es posible suspenderla, pasandola al
estado suspendida. En este estado, la red responde a peticiones de administracion
pero no responde frente a los eventos del mundo exterior. Es util suspender una
red en caso de que se deseen realizar labores de administracion sobre el sistema
que modela la red o sobre la red misma sin que la coherencia de los datos se
vea alterada por algun evento inesperado. Por otra parte, existe una operacion
de administracion (resumir) que hace que una red pase del estado suspendida al
estado en ejecucion. Si una red suspendida pasa mas de cierto tiempo en este
estado sin ser resumida, el motor tambien la pasa al estado pasiva y la elimina
de la memoria. Cualquier peticion que se realice sobre una red suspendida que
haya pasado al estado pasiva (con excepcion de una peticion de eliminacion que
sera procesada directamente) causara la recuperacion de la red de la base de
datos, pasandola nuevamente al estado suspendida.
Finalmente, el estado pasiva es opcional cuando el motor se utiliza como una
librerıa (siempre esta presente si el motor corre como servicio). Esto generalmente
es util si una aplicacion desea hacer uso de redes de Petri de corta vida sin que
sea necesario almacenarlas en una base de datos.
40 Arquitectura del Sistema
4.2.3. Interfaz Remota y Local
Las interfaces brindan una API adecuada, transparente y estandar para ma-
nejar y acceder a las operaciones brindadas por el motor y enumeradas en la lista
anterior. La interfaz remota permite utilizar el motor como un servicio, es decir,
el motor corre en alguna maquina esperando a que clientes corriendo en otras
maquinas se conecten y realicen alguna clase de peticion. Por otra parte, la inter-
faz local hace que el motor se comporte como una librerıa de modo que pueda ser
incrustado directamente en una aplicacion. En general, desde el punto de vista de
la interfaz y salvo algunos cambios menores, el cliente no debe poder diferenciar
entre una u otra interfaz, esto con el fin de que exista la mayor uniformidad y
portabilidad posible en la utilizacion del motor.
4.2.4. El Editor de Redes de Petri
El editor es un modulo que permite dos funciones basicas, la primera, facilitar
la creacion de redes de Petri brindandole al usuario las comodidades de una
herramienta de edicion grafica. La segunda, servir como interfaz de administracion
para cualquier motor que este corriendo como servicio, permitiendo importar,
exportar, suspender, resumir y eliminar redes de Petri. Ademas, el editor debe
permitir la simulacion, el monitoreo de redes de Petri que corran en un motor
configurado como servicio, asi como de igual forma debe permitir estimular (enviar
eventos) a alguna red en ejecucion.
4.2.5. Los Clientes
Los clientes pueden acceder al motor de ejecucion de dos formas: localmente o
remotamente. Si un cliente necesita utilizar redes de Petri de modo que sea posible
compartirlas con otros clientes o procesos entonces deberıa utilizar el motor como
un servicio, que corre independiente sobre un servidor de aplicaciones, de modo
que pueda ser accedido por todas las partes interesadas. Ademas, esto garantizarıa
la persistencia de las redes de Petri a lo largo del tiempo, de forma tal que la
4.3 Arquitectura del Motor 41
red se transforma en un ente independiente que no necesita al cliente que la
creo corriendo para para poder funcionar.
Por otra parte, es posible que un cliente este interesado en utilizar ciertas
redes de Petri por periodos de tiempo muy cortos, sin compartirlas con otros
procesos o clientes y opcionalmente sin que la red sea almacenada y persista entre
dos ejecuciones distintas de un mismo cliente. En este caso, el motor deberıa ser
utilizado como librerıa, estando disponible solo para el cliente que lo haya creado,
y opcionalmente sin que exista persistencia a largo plazo de las redes de Petri entre
dos sesiones diferentes.
4.3. Arquitectura del Motor
Conceptualmente, la interfaz del motor esta dividida en tres partes distintas y
bien diferenciadas: Interfaz de administracion, capturador de eventos y notifica-
cion de sucesos. En la Figura 4.3 se muestran los distintos modulos que componen
el motor. En general, a la izquierda se aprecian las interfaces del motor con el
mundo exterior, mientras que a la derecha se puede ver la division de modulos
interna del mismo.
La interfaz de administracion brinda soporte a todas las operaciones de ad-
ministracion del motor (registrar, eliminar, suspender, resumir y consultar redes
de Petri). Por otro lado, la interfaz del capturador de eventos se encarga de re-
cibir eventos del mundo exterior para introducirlos en la cola de eventos. Estas
interfaces reaccionan y se activan frente a ordenes de clientes del mundo exterior,
cosa que no ocurre con la interfaz de notificacion de sucesos que se encarga (pre-
via sub) de notificarle a clientes del mundo exterior que algun cambio ocurrio en
alguna red.
4.3.1. Capturador de Eventos
El capturador de eventos se encarga de recibir los eventos del mundo exterior
y colocarlos en una cola de donde seran tomados por el manejador de eventos. Por
42 Arquitectura del Sistema
de sucesosNotificacion
BDadministracionInterfaz de
de eventosCapturador
Redes de PetriRepositorio de
Cola de Eventos
ComponentesSucesos
Manejador de
Manejador deEventos
Figura 4.3: Arquitectura del Motor
razones de eficiencia, tanto el capturador como el manejador de eventos deben
correr en hilos diferentes, asi que la cola que sirve de intermediaria debe estar
debidamente sincronizada. En general, estos modulos siguen un esquema produc-
tor / consumidor, donde el capturador se activa solo para cuando llega un evento
para introducirlo en la cola, mientras que el manejador se activa para consumir
eventos de la cola.
4.3.2. Repositorio de Redes de Petri
El repositorio de redes de Petri se encarga de suministrarle al manejador de
eventos las redes de Petri necesarias para procesar los eventos almacenados en
la cola de eventos. Ademas, se encarga de manejar la persistencia transparente
(desde el punto de vista de los demas modulos) de las redes de Petri en la base de
datos, ası como las polıticas necesarias para determinar que redes se mantienen
en memoria con el objetivo de mejorar el rendimiento (Cache de redes). Por
otra parte, brinda los metodos necesarios para que los metodos de la interfaz de
4.3 Arquitectura del Motor 43
administracion pueda realizar todas las operaciones que le sean requeridas sobre
las redes de Petri del repositorio.
En general, el repositorio de redes es el unico modulo que esta al tanto de
que las redes de Petri son almacenadas en una base de datos, los demas modulos
solo utilizan las redes suministradas por el repositorio, independientemente de
que haya que buscarlas en una base de datos o se encuentren ya en memoria.
4.3.3. Manejador de Eventos
El manejador de eventos tiene la responsabilidad de tomar eventos de la cola
de eventos, obtener la red de Petri correspondiente del repositorio de redes y
ejecutarlo sobre la red de Petri. En general, este es el modulo principal del motor,
ya que es el encargado del procesamiento de los eventos, disparo de las transiciones
y ejecucion de las aristas y lugares. Por otra parte, debe manejar las situaciones
de conflicto efectivo en las transiciones, ası como la concurrencia de eventos sobre
una misma red o sobre recursos compartidos (lugares) de dos redes.
4.3.4. Manejador de Sucesos
El manejador de sucesos se encarga de notificar a los clientes sobre los distintos
sucesos (eventos al fin, pero no desde el punto de vista de una red de Petri) que
ocurren en el motor. Los clientes se registran con este modulo para ser notificados
cuando una red sea eliminada, suspendida, resumida o registrada. Ademas, dicho
modulo es capaz de enviar notificaciones a los clientes cuando una red de Petri
cambia de estado por causa del disparo de una transicion.
4.3.5. Componentes
Los componentes (en colaboracion con el documento que es explicado mas ade-
lante) son la piedra angular del mecanismo de expansion del motor de ejecucion.
En este caso, en particular, un componente es un pequeno modulo de software
que interactua con el motor, una o mas redes de Petri, otros componentes, y que
44 Arquitectura del Sistema
representa un “tipo” de transicion, arista o lugar. En general, es posible pensar en
un “tipo” de componente como se piensa en una “clase” u objeto en un lenguaje
de programacion orientado a objetos como JavaTM o C++. En otras palabras,
un componente define el comportamiento general que debe tener un lugar, aris-
ta o transicion, pero una red de Petri puede contener muchas instancias de un
mismo tipo de componente, cada una con parametros distintos, y que reaccionan
independientemente segun el evento recibido y la configuracion de la instancia.
El motor debe brindar una serie de componentes basicos, pero los usuarios
del mismo pueden agregar y programar componentes a medida que van siendo
necesarios. De esta forma, si existe un problema o una red que no es posible atacar
utilizando el conjunto de componentes ya existentes en el motor, entonces siempre
es posible programar una transicion, arista o lugar que pueda ser utilizado en una
red siempre que se desee.
4.4. Arquitectura del Editor
El editor basa su arquitectura en el modelo documento - vista, que define un
documento (informacion a mostrar y editar) y una serie de vistas distintas sobre
el documento. La Figura 4.4 muestra la arquitectura general del editor y sus
distintos modulos. Ademas, en lıneas punteadas, se aprecia la relacion del editor
con las distintas interfaces del motor de ejecucion (o el uso que hace el editor del
motor).
4.4.1. Interfaz Principal
La interfaz principal es la raız de toda la aplicacion. Su funcion principal es
interactuar con el usuario y permitirle acceder al resto de la aplicacion. Sirve
de padre y contenedor para las vistas y de punto de entrada para la interfaz de
administracion y otras funcionalidades de la aplicacion.
4.4 Arquitectura del Editor 45
de eventosCapturador
de sucesosNotificacion
administracionInterfaz de
PrincipalInterfaz
Interfaz deAdministracion
Vista (Red de Petri)Documento
Motor
MotorMotor
Figura 4.4: Arquitectura del Editor
4.4.2. Interfaz de Administracion
La interfaz de administracion es la encargada de presentarle al usuario la posi-
bilidad de administrar un motor de ejecucion. En general, debe permitir registrar,
eliminar, suspender y resumir redes en el motor seleccionado, pero ademas, debe
permitir listar e importar las redes que esten en ejecucion. Este modulo es el
encargado de hablar con la interfaz de administracion de un motor en particular.
4.4.3. Vista
La vista, tiene como funcion tomar una instancia en particular de un docu-
mento para mostrarlo al usuario y permitirle, segun sea el caso, interactuar con el
mismo. Existe una asociacion uno a uno entre la vista y su documento, es decir,
en un momento determinado una vista puede estar mostrando solo a un docu-
mento. En general, existen dos modos para la vista, el primero, que permite al
usuario editar el documento, y el segundo que sirve unicamente para supervisar
y enviarle eventos a una red de Petri corriendo en un motor de ejecucion (local o
remoto). La vista interactua con el capturador de eventos del motor (para enviar-
le manualmente un evento a una red) y con la interfaz de notificacion de sucesos
46 Arquitectura del Sistema
(para detectar cambios en una red que se este supervisando)
4.4.4. Documento
Como objetivo principal, el documento debe manejar toda la logica de la
informacion que contiene, ası como los detalles sobre el almacenamiento del mismo
en un medio persistente. Ademas, el documento es la forma estandar que tienen
el motor el editor y cualquier otro modulo de almacenar y representar redes de
Petri en memoria.
Capıtulo 5
Implementacion
En general, todos los modulos se implementaran utilizando JavaTM. Esta
decision se toma basicamente en funcion de las bondades de dicho lenguaje y
de su fortaleza a la hora de desarrollar rapida y eficientemente aplicaciones de
gran envergadura, portabilidad y flexibilidad. Ademas, para todos los documentos
utilizados en el sistema, archivos de configuracion y documentos en general, el
comun denominador es la utilizacion de XML como formato.
5.1. El API de Componentes
El API de componentes permite que se puedan anadir elementos nuevos (lu-
gares, transiciones, aristas) al motor. Eso es posible gracias a la definicion de un
API estandar que permita insertar dinamicamente nuevos componentes a medida
que estos se van programando. La Figura 5.1 muestra el diagrama de clases del
API de componentes del motor de ejecucion y el editor de redes de Petri. En ge-
neral, el sistema brinda una serie de interfaces (desde el punto de vista JavaTM)
que deben ser implantadas para poder definir un nuevo componente.
Un componente representa la definicion de tipo, es decir, es equivalente a la
definicion de tipo de dato en un lenguaje de programacion. De esta forma, es
posible que existan muchas instancias distintas de un mismo tipo en una red de
48 Implementacion
Petri, diferentes todas entre si, pero que tienen en comun ciertas caracterısticas
funcionales.
Figura 5.1: Diagrama de Clases del API de Componentes
Para crear un nuevo tipo de componente (transicion, lugar o arista) basta con
implementar adecuadamente las interfaces de la Figura 5.1 y registrar el nuevo
tipo en el archivo descriptor de componentes (ver mas adelante). En general, el
tipo debe ser registrado en cada instancia de motor o editor en el que se utilice,
asi como de igual forma, es necesario que las clases que implantan el tipo esten
disponibles en dichas instancias.
5.1.1. Data del Componente ComponentData
Esta interfaz concentra toda la informacion que un componente necesita para
funcionar. Las propiedades de un componente deben definirse utilizando objetos
de tipo XDataObject, los cuales deben tener su respectiva descripcion utilizando
un objeto de tipo XClass (ver apendice B). La utilizacion de XClass es bastante
5.1 El API de Componentes 49
intensiva a lo largo de todo el proyecto, ası que se recomienda tener nociones
sobre su funcionamiento y filosofıa.
La interfaz define una serie de metodos que permiten manipular y modificar
los XDataObject de una instancia de componente en particular. Tales metodos son
addDataObject, getDataObject, delDataObject, dataObjectIterator y toDataObjec-
tArray. El funcionamiento de cada uno de estos metodos se describe por completo
en la API del proyecto (ver JavaDocs anexos en digital).
Ademas, se definen metodos para manipular la informacion comun a todos los
tipos de componentes y que esta asociada a las tres clases basicas: transiciones,
aristas y lugares. Esta informacion comun consiste en el nombre de la instancia
(metodos get / setName), el nombre del evento asociado si el componente es una
transicion (metodos get / setEvent), la clase o tipo basico de componente (tran-
sicion, arista, lugar, accesible por el metodo getType) y la fabrica que genero el
componente (metodo get / setFactory, ver seccion 5.1.4).
Por otro lado, no siempre es estrictamente necesario implementar esta interfaz
directamente, ya que existen una serie de clases predefinidas para cada tipo basico
que ya lo hacen, ası que en general basta con heredar de alguna de dichas clases.
En la Figura 5.4 se muestran las clases que conforman el documento y su relacion
con las clases del API de componentes. Como se aprecia, las clases TransData,
EdgeData y PlaceData heredan de ComponentDataImpl que a su vez implantan
la interfaz ComponentData.
En otras palabras, si se desea implantar algun tipo de componente en par-
ticular, lo normal es heredar de TransData, EdgeData o PlaceData o utilizar
instancias de dichas clases (que es lo mas comun). De modo que basta con relle-
nar cada instancia de las clases mencionadas anteriormente con los XDataObject
adecuados segun sean las necesidades del componente.
5.1.2. Objeto Acuarela ComponentObject
El objeto acuarela es el encargado de la visualizacion y edicion grafica del
componente y es utilizado solo en el editor e ignorado por completo en el motor
50 Implementacion
de ejecucion.
Figura 5.2: Diagrama de Clases de los Objetos Acuarela Predeterminados
En general, Acuarela hace la separacion entre el comportamiento logico del
objeto al momento de mostrarse (representado por un AObject) y de la forma
de dibujar o pintar al mismo (ARenderer). Es decir, un AObject define como
se comporta el objeto en el lienzo, mientras que un ARenderer determina como
debe pintarse. Si bien dos transiciones de distinto tipo se comportaran de la
misma forma en el editor, estas no deberan verse igual, de modo que puedan ser
diferenciadas entre si. Esto se logra haciendo que todos los tipos de transiciones
tengan un mismo tipo de AObject, pero diferentes objetos ARenderer.
El editor define tres clases AObject predeterminadas (ver Figura 5.2) que
deben ser suficiente para cualquier tipo de componente nuevo que se desee im-
plantar. ATrans representa el comportamiento de una transicion, AEdge el de
una arista y APlace el de un lugar.
5.1 El API de Componentes 51
Figura 5.3: Diagrama de Clases de los Renderers Acuarela Predeterminados
Como se menciono anteriormente, la diferencia visual entre dos componentes
consiste en el objeto ARenderer de cada uno de ellos. En general, el editor trata
de mantener cierta coherencia visual entre los distintos componentes, razon por la
cual, define una serie de objetos ARenderer por defecto para cada uno de los tipos
basicos de componentes (Figura 5.3). Cualquier componente nuevo debe tener un
ARenderer que herede de alguna de estas clases basicas, de modo que cualquier
detalle visual adicional, particular al componente, se dibuje en el metodo paint
sobrecargado de la clase padre.
5.1.3. Objeto de Ejecucion ComponentRuntime
El objeto de ejecucion es el encargado de ejecutar y verificar si un componente
esta habilitado. Todos los componentes deben tener un objeto de ejecucion, que
se obtiene implantando la interfaz ComponentRuntime. Esta interfaz define los
metodos basicos que el motor necesita para poder ejecutar el componente.
El metodo initComponentRuntime es invocado por el motor para inicializar
el componente, recibiendo como parametros la red de Petri a la que pertenece el
componente, la instancia de ComponentData correspondiente al componente y el
contexto de ejecucion, que es un mapa que contiene todos los ComponentRuntime
que se han utilizado hasta el momento durante la ejecucion del evento en curso.
Este mapa permite reutilizar los objetos ComponentRuntime que ya han sido ini-
cializados, de modo que sea posible establecer un ambiente transaccional optimo
52 Implementacion
entre los componentes. En otras palabras, si se necesita un ComponentRuntime,
este debe buscarse primero en el contexto de ejecucion, y si no es encontrado,
entonces se puede proceder a crearlo e inicializarlo.
Los metodos testComponentRuntime y fireComponentRuntime se encargan
de verificar el estado y ejecutar el componente respectivamente. El primero, sim-
plemente determina si el componente esta habilitado y no debe realizar ningun
cambio persistente en el mismo (por ejemplo, modificar un registro de una ba-
se de datos). El segundo, es invocado al momento de ejecutar un componente.
Este ultimo metodo puede modificar los datos del componente o de algun otro
repositorio de datos, pero no puede hacer los cambios persistentes hasta que no
sea invocado el metodo commitComponentRuntime, o debe de poder deshacer
cualquier cambio en caso de que el motor invoque a rollbackComponentRuntime.
Estos metodos retornan verdadero si el componente esta habilitado o si la ejecu-
cion del mismo termino con exito. En la seccion 5.3, mas adelante, se muestra
el ciclo de vida de un ComponentRuntime y el orden en que el motor invoca los
metodos del mismo.
5.1.4. Fabrica de Componentes ComponentFactory
La fabrica de componentes es la interfaz que aglutina toda la API de com-
ponentes. Todo componente debe brindar una clase que implemente la interfaz
ComponentFactory. Dicha clase debe ser fuente de informacion basica del com-
ponente, como por ejemplo, el ıcono que el editor debe utilizar en la barra de
herramientas para representar el componente (getIcon), el nombre base del tipo
de componente (getName) y la clase basica de componente (getType). De igual
forma, la fabrica de componentes debe permitir obtener instancias ya inicializa-
das de las interfaces ComponentData (getData), ComponentObject (getObject) y
ComponentRuntime (getRuntime).
5.2 El Documento 53
5.1.5. Archivo Descriptor de Componentes
El archivo descriptor de componentes contiene la lista de fabricas de compo-
nentes disponibles para un editor o motor de ejecucion. Consiste en una lista de
nombres de clases completamente calificados que implantan ComponentFactory.
Todo componente debe estar registrado en este archivo para que pueda funcionar
apropiadamente. El formato del archivo XML se muestra a continuacion:
<plugins>
<plugin factory="..."/>
...
<plugin factory="..."/>
</plugins>
5.2. El Documento
El documento es la representacion en memoria o en disco de una red de Pe-
tri. Todos los modulos que interactuan con redes de Petri (editor y motor de
ejecucion) comparten la estructura del documento.
5.2.1. Representacion del Documento en Memoria
Una red de Petri se puede manipular y mantener en memoria mediante una
serie de clases. Estas clases son TransData (representa transiciones), EdgeData
(aristas), PlaceData (lugares) y PNetData (ver Figura 5.4). Esta ultima represen-
ta una red de Petri completa, y no es mas que un conjunto de clases TransData,
EdgeData y PlaceData dispuestas en forma de grafo dirigido.
Las clases TransData, EdgeData y PlaceData implantan ComponentData,
ası que dada la necesidad de programar un nuevo componente, pueden utilizarse
estas clases en lugar de hacer una que implante ComponentData.
54 Implementacion
Figura 5.4: Diagrama de Clases del Documento
5.2.2. Representacion del Documento en XML
Por otra parte, tambien es necesario poder almacenar redes de Petri en un
medio persistente como un disco o en una base de datos. Por esta razon, se define
un documento en XML que representa una red de Petri y que puede obtenerse
a partir de la representacion en memoria de la red. De igual forma, a partir del
documento, se puede obtener la representacion en memoria de una red de Petri.
El formato del documento se muestra a continuacion:
<petrinet>
<place name = "..." type = "...">
5.2 El Documento 55
<data-object name = "..." type = "...">
<property key = "..." value = "..."/> ...
</data-object>
</place>
...
<transition name = "..." type = "..." event = "...">
<data-object name = "..." type = "...">
<property key = "..." value = "..."/> ...
</data-object>
</transition>
...
<edge name = "..." type = "..." src = "..." dst = "...">
<data-object name = "..." type = "...">
<property key = "..." value = "..."/> ...
</data-object>
</edge>
<event name = "...">
<class name="..."></class>
</event>
...
</petrinet>
El archivo consta de una lista de lugares, en donde se describe para cada uno
de ellos su nombre y su fabrica de componentes (name y type respectivamente).
Ademas, cada lugar contiene una lista de objetos XDataObject representados en
XML (ver mas adelante). Luego, viene una lista de transiciones, cada una de las
cuales contiene su nombre, su fabrica de componentes, el nombre del evento al que
esta asociada (name, type y event), y al igual que los lugares, una lista de objetos
XDataObject. Inmediatamente despues, aparece una lista de aristas, donde para
cada una de ellas se describe su nombre, fabrica de componentes, el nombre del
nodo origen y el nombre del nodo destino (name, type, src y dst). Al igual que
56 Implementacion
los lugares y transiciones, las aristas tambien poseen una lista de XDataObject.
Los objetos XDataObject se codifican en XML, especificando su identificador
y el nombre completamente calificado del XClass que lo describe (name y ty-
pe). Ademas, cada XDataObject posee una lista de propiedades tipo clave-valor
que representa la informacion que contenıa el objeto en el momento en que se
almaceno como XML.
Finalmente, el archivo contiene una lista de eventos que pueden afectar a
la red de Petri, describiendo para cada uno de ellos su nombre y especificando
un XClass que define los parametros que pueden venir adjuntos al evento. Una
descripcion mas completa y complementaria del formato del documento en XML
se puede apreciar en el apendice A.
En general, todos los modulos del sistema necesitan manejar ambas represen-
taciones de una red de Petri (en memoria y en XML), pero mas importante aun es
la necesidad de obtener una a partir de la otra. La clase PNetFactory cumple esta
funcion, brindando una serie de metodos (todos estaticos) que permiten obtener
el XML correspondiente a partir de un objeto PNetData y viceversa.
5.3. El Motor de Ejecucion
5.3.1. Interfaz de Administracion, Capturador de Eventos
La Figura 5.5 muestra el diagrama de clases de las interfaces en general. Los
metodos de administracion y capturador de eventos son brindados en la inter-
faz EngineBusiness. Dicha interfaz brinda metodos acordes con las necesidades
de administracion (revisar seccion 4.2.1) y ademas permite enviar un evento a
una red en particular utilizando el metodo fireEvent. En general, esta interfaz es
constante, tanto si se usa el motor como librerıa o como servicio. Si el motor es
utilizado como servicio, entonces este se implanta con un Enterprise Java Bean
corriendo en un servidor de aplicaciones. En general, no existe diferencia desde
el punto de vista del cliente al utilizar el motor como servicio o como librerıa,
5.3 El Motor de Ejecucion 57
excepto que en el primer caso es necesario obtener una instancia de la interfaz
hogar del bean (utilizando JNDI) y en el segundo caso basta con instanciar el
motor para poder utilizarlo localmente.
Figura 5.5: Diagrama de Clases de la Interfaz del Motor
Existen tambien varias clases auxiliares que sirven para facilitar la comuni-
cacion entre el cliente y el motor. Estas clases son PNetQuery, TransQuery y
PNetEvent. La primera sirve para encapsular la informacion referente al estado
de ejecucion de una red de Petri (suspendida o ejecutando), y se utiliza funda-
mentalmente en el metodo queryPNet de EngineBusiness para listar las redes
que estan corriendo en un motor de ejecucion. La clase TransQuery se utiliza
para obtener, por medio del metodo queryTrans, la lista de transiciones de una
red y el estado de cada una de ellas (habilitada, deshabilitada o indeterminado).
Finalmente, PNetEvent representa un evento y es utilizado como parametro del
metodo fireEvent.
58 Implementacion
5.3.2. Manejador de Sucesos
El manejo de sucesos (o notificaciones a los clientes) se implanta utilizando
la arquitectura estandar de eventos de Java, es decir, un cliente registra una
interfaz “listener” con una fuente de eventos y espera que esta invoque a alguno
de los metodos de la interfaz como respuesta a un evento. Un cliente de un
motor puede registrar una o mas instancias de tipo EngineListener (que es un
“listener” convencional de Java), de modo que pueda recibir eventos segun los
genere el motor. La interfaz no se registra directamente sobre el motor, sino sobre
una instancia de tipo EngineInfo. Este rodeo permite tener una forma estandar
de registrar “listeners” con un motor, independientemente de que este corriendo
local (librerıa) o remotamente (servicio).
El motor envıa notificaciones cuando una red cambia de estado, es removida,
suspendida o resumida, y correspondientemente, los metodos pNetChanged, pNe-
tRemoved, pNetSuspended y pNetResumed, de cualquier interfaz EngineListener
registrada, son invocados. Si el motor esta corriendo de forma local, hacer llegar
las notificaciones a los “listener” no resulta en lo absoluto un problema, pero si
el motor corre como servicio de forma remota, esto puede ser complicado. En el
ultimo caso, la solucion consiste en hacer llegar las notificaciones por medio de
un servicio de mensajerıa JMS a una instancia de tipo EngineInfo, de modo que
esta pueda repartirlas a cada uno de sus “listener” locales registrados.
5.3.3. Repositorio de Redes de Petri
En la Figura 5.6 se muestra el diagrama de clases del motor de ejecucion, que
basicamente esta compuesto por el repositorio de redes de Petri y el manejador de
eventos del motor. La clase PNetRepository provee una interfaz bastante simple
para manejar las redes de Petri del repositorio. Hay metodos para agregar nuevas
redes al repositorio, eliminarlas del repositorio, obtener una red en particular o
listar las redes del repositorio (metodos addPNet, delPNet, getPNet y getPNets
respectivamente).
5.3 El Motor de Ejecucion 59
Figura 5.6: Diagrama de Clases del Motor
En general, si el objeto PNetRepository es creado con un objeto de tipo ja-
va.sql.Connection (ver JDBC en la apendice B) como parametro del constructor,
entonces el repositorio utilizara dicha conexion para almacenar y recuperar redes
de una base de datos. Si la conexion no se especifica al momento de instanciar el
repositorio, entonces este asumira que no se desea hacer persistentes las redes en
una base de datos. Cuando el motor corre como una librerıa, el cliente es respon-
sable de inicializar el objeto java.sql.Connection y de pasarlo como parametro al
motor al momento de instanciarlo.
Por otra parte, si el motor corre como un servicio en un servidor de apli-
caciones, entonces el objeto java.sql.Connection es localizado utilizando JNDI,
mediante como nombre de la referencia “java:/PNetDS”. El servidor de aplica-
ciones debe ser correctamente configurado para que el motor pueda obtener un
java.sql.Connection mediante JNDI, utilizando “java:/PNetDS” como referencia.
Sin embargo, si el motor no puede obtener un java.sql.Connection, entonces asu-
mira que no es necesario conectarse con una base de datos, y mantendra todas
las redes de Petri en memoria mientras que el servicio este funcionando.
La base de datos utilizada por el motor consta de una sola tabla llamada
60 Implementacion
“pnets”. La tabla debe tener tres campos para que se puedan almacenar redes
de Petri: El primero es el identificador unico de la red, debe llamarse “id” y ser
de tipo “VARCHAR(50)” (ademas es la clave primaria de la tabla). El segundo
campo representa el estado de ejecucion de la red (ejecutando o suspendida),
debe llamarse “status” y ser de tipo entero. El motor utiliza un valor 0 para
indicar que una red esta corriendo y un valor 1 para indicar que esta suspendida.
Finalmente, el tercer campo, representa el contenido de la red en forma de XML.
Este campo debe ser de un tipo que soporte cadenas de caracteres de longitud
variable (el nombre del tipo varıa mucho entre los distintos manejadores de bases
de datos) y debe llamarse “data”. Como ejemplo, a continuacion se muestra la
sentencia SQL utilizada para crear la tabla “pnets”, utilizando PostgreSQL como
manejador de base de datos:
CREATE TABLE pnets
(
id VARCHAR(50) PRIMARY KEY,
status INT,
data TEXT
);
5.3.4. Manejador de Eventos
El manejador de eventos, que es implantado por la clase EngineImpl, se en-
carga de todo lo relacionado con el procesamiento de un evento por el motor.
Ademas, esta clase implementa EngineBusiness y sirve de puente entre la inter-
faz de administracion y el repositorio de redes de Petri. Formalmente, esto resulta
ser una variacion de la arquitectura del motor de la Figura 4.3. Sin embargo, tal
cambio en la implantacion hace mas facil brindarle al cliente una interfaz ho-
mogenea, tanto si el motor es utilizado localmente o como un servicio. De hecho,
si el motor funciona como servicio, entonces la clase EngineImpl es instancia-
da y utilizada dentro de un Enterprise Java Bean, mientras que si es utilizado
5.3 El Motor de Ejecucion 61
localmente, el cliente accede directamente a la clase EngineImpl.
En general, esta clase maneja todo lo relacionado con la concurrencia de even-
tos, procesandolos secuencialmente, de manera que dos eventos nunca se ejecuten
al mismo tiempo. Si bien esta tecnica es poco eficiente, debido a que eventos que
podrıan ejecutarse concurrentemente de una forma perfecta y sin peligro no lo
hacen, lo que permite garantizar facilmente la integridad de la informacion con-
tenida en las redes de Petri. Sin embargo, en el futuro es recomendable implantar
esta clase de forma que dos o mas eventos puedan ejecutarse de forma simultanea
(ver recomendaciones en la seccion 6.2).
transicionSeleccionar primera
testComponentRuntime
¿Habilitada?
Almacenar en una lista
transiciones?¿Mas
transicionSeleccionar siguiente
Inicio
Fin
initComponentRuntime
Si
No
No
Si
Figura 5.7: Ejecucion de un Evento (Primera Etapa)
Cuando llega un evento al sistema, el motor lo procesa en dos etapas, una
de verificacion y otra de ejecucion. Basicamente, la primera etapa consiste en
inicializar los objetos ComponentRuntime (), agregarlos al contexto de ejecucion,
determinar que transiciones estan habilitadas y almacenarlas en una lista para
ejecutarlas posteriormente. La primera etapa sigue los pasos del diagrama de
flujo de la Figura 5.7, en ella son instanciados los objetos ComponentRuntime
e invocados los metodos initComponentRuntime y testComponentRuntime. El
objetivo de esta etapa es generar una lista de transiciones habilitadas, sin alterar
la informacion de la red de Petri asociada al evento que se esta procesando.
62 Implementacion
Sacar transiciones conmayor precedencia de la
lista
Ejecutar transiciones
¿Ejecutarontodas bien?
aborta (rollback)La transaccion del nivel
La transaccion (Evento)finaliza bien (commit) transiciones?
¿Mas
Fin
InicioOrdenar lista por
precedencias
Si
No
Si
No
Figura 5.8: Ejecucion de un Evento (Segunda Etapa)
La segunda etapa (ver Figura 5.8) se encarga de ejecutar las transiciones habi-
litadas almacenadas en la lista generada por la primera etapa. Esta etapa agrupa
las transiciones habilitadas por precedencia, y trata de ejecutar en bloque y de
forma transaccional todas las transiciones asociadas a un mismo nivel de pre-
cedencia. Si alguna de las transiciones falla en su ejecucion (por problemas de
conflicto, ver secciones 2.1.7 y 3.2.1), entonces la ejecucion del nivel de prece-
dencia actual es abortada y las transiciones son alertadas por medio del metodo
rollbackComponentRuntime para que deshagan cualquier cambio realizado. Por
otro lado, si todas las transiciones de un mismo nivel de precedencia tienen exito
en su ejecucion, entonces son notificadas mediante el metodo commitComponen-
tRuntime para que hagan persistente cualquier cambio realizado.
5.4. El Editor de Redes de Petri
El editor de redes es la aplicacion que permite generar facilmente redes de
Petri e interactuar de forma sencilla y amigable con un motor de ejecucion. Su
5.4 El Editor de Redes de Petri 63
objetivo fundamental es automatizar la creacion de los archivos que definen las
redes mediante un ambiente grafico (seccion 5.2.2). En general, toda la GUI del
editor esta implantanda utilizando algunos componentes de MBeans y otros de
Swing, y la interfaz hombre-maquina, que permite editar y visualizar las redes de
Petri, fue desarrollo por completo utilizando Acuarela (ver apendice B)
Figura 5.9: Diagrama de Clases del Editor
5.4.1. Clases del Editor de Redes de Petri
En la Figura 5.9 se muestra el diagrama de clases del editor. La clase FrmMain
implanta la ventana principal del editor y sirve como punto de entrada al mismo.
En general, esta clase cumple el papel de “director de orquesta” de la aplicacion,
siendo la encargada de leer el archivo descriptor de componentes, inicializar las
fabricas de componentes, instanciar el motor de ejecucion interno del editor y
crear toda la GUI principal.
Por otra parte, tanto la clase FrmServer como FrmExport son las responsables
de establecer la conexion con un motor de ejecucion (tanto el interno del editor
64 Implementacion
como cualquier motor que este corriendo remotamente como servicio). La primera
de estas clases maneja todo lo relacionado a la administracion de un motor de
ejecucion (listar, eliminar, suspender o resumir redes de Petri), mientras que la
segunda, maneja todo lo vinculado con importar y exportar redes de Petri hacia
y desde el motor.
La clase FrmEditor implanta la vista (ver Figura 4.4) y es la encargada de
interactuar con el documento y con Acuarela para permitir la edicion de redes
de Petri. Esta clase tiene dos modalidades de ejecucion; la primera permite al
usuario crear y editar redes de Petri, y la segunda le permite conectarse a una
red que este corriendo en algun motor con el fin de supervisarla y/o enviarle
eventos manualmente.
Capıtulo 6
Conclusiones y Recomendaciones
6.1. Conclusiones
En general, la idea de disponer de un motor de ejecucion de redes de Petri
resulta bastante atractiva. Esto se debe a la gran cantidad de sistemas que se
pueden modelar utilizando redes de Petri. Si bien inicialmente este proyecto fue
concebido para hacer un motor de ejecucion de redes de Petri con el fin de modelar
sistemas de produccion (sobre todo pensando en el enfoque holonico), a medida
que se desarrollaba el software, se pudo apreciar que la utilidad del motor no se
limita unicamente a esas ramas de la industria. De hecho, una gran cantidad de
sistemas pueden ser modelados por medio de este tipo de redes, desde procesos
de produccion, sistemas de inteligencia artificial, sistemas de informacion, etc.
El autor de este proyecto esta particularmente ligado al mundo del desarrollo
de software, y se ha encontrado en mas de un momento frente a sistemas complejos
que pueden ser facilmente modelados utilizando redes de Petri, pero que, sin
embargo, resultan una verdadera pesadilla al momento de implantarlos. De esta
manera, si bien luego de programar varias soluciones similares, se puede definir
un mecanismo comun a la hora de atacar esta clase de problemas, no queda mas
remedio que reinventar la rueda en cada problema de este tipo. Sin embargo, al
disponer de un motor de ejecucion de redes de Petri se tiene una herramienta
66 Conclusiones y Recomendaciones
poderosa que puede utilizarse para atacar esta clase de problemas siempre de la
misma forma. Mejor aun, si la herramienta puede expandirse facilmente, entonces
se garantiza de esta forma que nunca escaseara un componente determinado.
Por todas estas razones, el autor considera que ademas del motor de ejecucion,
los aportes mas importantes del presente trabajo son la definicion de un formato
de archivo XML que permita describir redes de Petri, ası como la especificacion
de una arquitectura de componentes que permite expandir facilmente el motor
y cualquier aplicacion que utilice redes de Petri. En el primer caso, un archivo
estandar que sirve para describir y definir redes, permite el intercambio de las mis-
mas entre distintas aplicaciones. Por otra parte, la arquitectura de componentes
permite definir lugares, aristas y transiciones con casi cualquier comportamiento
deseado. Esto, en conjunto con el formato de archivo XML, se convierte en una
herramienta poderosa para definir, ejecutar, simular y editar redes de Petri.
El presente desarrollo (si bien es totalmente funcional) sirve como primera
aproximacion a la solucion del problema. De las aplicaciones en las que el motor
sea utilizado y de la experiencia obtenida desarrollando nuevos componentes se
deben derivar futuros trabajos al respecto. Sobre todo, es importante tener en
cuenta que existen muchos problemas en la industria (y no solo los relacionados
con la industria de la manufactura, sino tambien los relacionados con la industria
del desarrollo de software) que pueden ser facilmente resueltos utilizando redes de
Petri. Por esta razon, un motor que permita ejecutar tales tipos de redes, puede
resultar una herramienta invaluable, sobre todo si este se combina con software
pensado para manejar procesos de produccion, sobre todo dentro del enfoque
holonico.
6.2. Recomendaciones
Muchas de estas recomendaciones salen de la lista de “TODO”’s (“por hacer”)
del software, que generalmente esta formada por comentarios en el codigo fuente
del mismo. Es importante recordar que el desarrollo de software es un proceso de
6.2 Recomendaciones 67
constante aprendizaje sobre el problema que se esta resolviendo, de manera que
al implantar una solucion, pueden surgir miles de nuevas ideas que resultan ten-
tadoras de incorporar al proyecto. Sin embargo, es necesario hacer una distincion
clara de lo que es en verdad factible agregar, porque de lo contrario, se puede
caer facilmente en un desarrollo sin fin, que nunca culmina (o lo hace despues de
mucho tiempo), debido al contingente de cambios que se van haciendo a medida
que se implanta el software.
Por lo general, respecto al desarrollo de software y a la comprension del pro-
blema que se esta resolviendo, siempre me ha gustado una cita que tuve el agrado
de leer en un artıculo titulado “La Catedral y el Bazar” (Eric S. Raymond, 2000):
No se entiende cabalmente un problema hasta que se implementa
la primera solucion. La siguiente vez quizas uno ya sepa lo suficiente
para solucionarlo. Ası que si quieres resolverlo, disponte a empezar de
nuevo al menos una vez.
Lo cual no quiere decir, en lo absoluto, que no se deba conocer el problema
antes de comenzar a implementar la primera solucion, pero si que hay muchos
detalles que seran apreciados durante y una vez culminado el desarrollo. Es por
eso, que muchas de estas recomendaciones son sugerencias para una segunda
version, y que la misma deberıa estar precedida de un estudio sobre los escollos y
problemas con los que se ha topado esta primera version, para de esta forma, poder
reflexionar al respecto y atacar cualquier desarrollo posterior con una conciencia
mas profunda sobre el problema.
Hay que mejorar la arquitectura del API de componentes, de forma que se
pueda hacer una separacion eficiente entre el motor y el editor. Actualmente,
ambos modulos estan muy ligados entre si, lo que representa un error de
diseno, ya que por ejemplo, es necesario tener el jar de Acuarela en el
servidor de aplicaciones para que el motor pueda correr correctamente. Sin
embargo, esto se debe entre otras cosas, a un error de diseno en Acuarela,
que debe ser corregido antes de intentar tal separacion.
68 Conclusiones y Recomendaciones
Es fundamental mejorar el manejo de concurrencia del motor. El bloqueo a
nivel de eventos es extremadamente seguro, pero demasiado ineficiente para
un ambiente de produccion real. Por esta razon, es necesario implantar un
bloqueo a nivel de componentes e integrarlo con la nocion transaccional de
la ejecucion de un evento. Sin embargo, esto trae consigo las dificultades de
tener que manejar un grafo de recursos para poder luchar con situaciones
de abrazos mortales y otras complicaciones.
Es recomendable desarrollar un servicio Web que permita administrar un
motor y visualizar las redes de Petri que se esten ejecutando en el mismo.
Esto se puede desarrollar facilmente utilizando Servlet o JSP en conjunto
con la capacidad grafica de Acuarela.
Es recomendable separar la interfaz de administracion del capturador de
eventos para adaptarse completamente a la arquitectura de la Figura 4.3. La
independencia entre estas interfaces le da mas flexibilidad al motor cuando
corre como servicio, pero complica la API del mismo al momento de correr
como librerıa. En general, este punto y el siguiente pueden comprometer la
compatibilidad de la API del motor entre el modo local y el modo remoto,
haciendolas diferentes entre si.
Serıa importante a largo plazo implementar todas las interfaces del motor
(administracion, capturador de eventos y notificacion de sucesos), utilizando
JMS de forma asıncrona o, en el peor de los casos, utilizando un Message
Driven Session Bean en lugar de un Session Bean. Esto harıa mas sencilla la
comunicacion con el motor (desde el punto de vista del cliente y del servidor)
y permitirıa facilitar la portabilidad del motor entre distintos servidores de
aplicaciones.
En general, es importante mejorar la bitacora del motor y permitir hacer
una supervision remota del mismo. Tal mejora tiene como funcion facilitar
la depuracion de los componentes anadidos por el usuario y ademas llevar
6.2 Recomendaciones 69
un registro mas tangible de los distintos sucesos y eventos que ocurren en
el motor.
Es recomendable incrementar los niveles de seguridad del motor (en especial
cuando corre como un servicio y puede ser accedido de forma remota),
obligando a los clientes a identificarse por medio de un “login” y “password”.
Esto aumenta la complejidad de la base de datos y de las interfaces remotas
del motor, ya que por un lado es necesario almacenar una lista de usuarios, y
por el otro se debe implantar algun protocolo de autenticacion de usuarios.
Puede ser util modificar el repositorio de redes de Petri y la estructura
de tabla donde se almacenan las redes en la base de datos (ver seccion
5.3.3), para que pueda almacenar la ultima fecha de acceso a una red y
otras estadısticas de utilidad. Esto puede permitir establecer un control
mas profundo sobre las redes almacenadas y ademas sirve para eliminar de
la base de datos, redes que esten inactivas por un periodo mayor de cierto
tiempo.
Es necesario modificar la arquitectura de las transiciones, de modo que
pueda ser posible encadenar distintos efectos al momento de disparar una
transicion. Por ejemplo, puede ser necesaria una transicion que al dispararse
ejecute cierto codigo JavaTM y que ademas envıe un evento a otra transicion
(transiciones de las secciones 3.2.4 y 3.2.3 respectivamente)
Apendice A
Definicion de Redes de Petri en
XML
Una red de Petri se puede describir en XML mediante una lista de lugares,
transiciones, aristas y eventos. A continuacion se muestra un ejemplo de la es-
tructura del archivo XML:
<petrinet>
<place name = "..." type = "...">
<data-object name = "..." type = "...">
<property key = "..." value = "..."/>
...
</data-object>
...
</place>
...
<transition name = "..." type = "..." event = "...">
<data-object name = "..." type = "...">
<property key = "..." value = "..."/>
...
</data-object>
72 Definicion de Redes de Petri en XML
...
</transition>
...
<edge name = "..." type = "..." src = "..." dst = "...">
<data-object name = "..." type = "...">
<property key = "..." value = "..."/>
...
</data-object>
...
</edge>
...
<event name = "...">
<class name="..."></class>
</event>
...
</petrinet>
El XML contiene:
1. Una lista de lugares que se describen por medio de la etiqueta <place
name=”...”type=”...”>. Donde name contiene el nombre del lugar y ty-
pe el nombre de la clase JavaTM que implementa ComponentFactory y que
sirve de fabrica para las instancias del componente.
2. Una lista de transiciones que se describen por medio de la etiqueta<transition
name=”...”type=”...”event=”...”>. Donde name contiene el nombre de la
transicion, type el nombre de la clase JavaTM que implementa Component-
Factory y que sirve de fabrica para las instancias del componente y event
que corresponde al nombre del evento frente al cual responde la transicion.
3. Una lista de aristas que se describen por medio de la etiqueta <edge na-
me=”...”type=”...”src=”...”dst = ”...”>. Donde name contiene el nombre
A Definicion de Redes de Petri en XML 73
de la arista, type el nombre de la clase JavaTM que implementa Compo-
nentFactory y que sirve de fabrica para las instancias del componente, src
que es el nombre del nodo de origen (lugar o transicion) y dst que es el
nombre del nodo de destino (lugar o transicion).
4. Una lista de eventos asociados a la red que se describen por medio de la
etiqueta <event name=”...”>. Donde name contiene el nombre del evento.
Por otra parte, cada lugar, transicion o arista contienen una lista de data
objects que sirven para describir las propiedades particulares de los componentes.
Un data object se representa mediante la etiqueta <data-object name = ”...”type
= ”...”>, donde name es el nombre del objeto y type es su descripcion enXClass.
Cada data object contiene una lista de propiedades que se representan por medio
de etiquetas <property key = ”...”value = ”.../>, donde key representa el nombre
o la clave de la propiedad y value el valor de la misma. En general, dos instancias
distintas de un mismo tipo de componente comparten data objects del mismo tipo
y nombre, pero que estan parametrizados de forma distinta segun las necesidades
de cada instancia.
Finalmente, cada evento representado en la lista de eventos contiene un des-
criptor XClass que sirve para definir los parametros asociados al mismo. En el
apendice B se puede obtener informacion mas detallada respecto a XClass.
Por ejemplo, un lugar de fichas (ver seccion 3.3.2) puede describirse de esta
forma:
<place name="p1"
type="org.cyrano.pnet.plugins.plugins.TokenPlaceFactory">
<data-object name="aPlaceData"
type="org.cyrano.pnet.editor.acuarela.APlaceData">
<property key="X_obj" value="168"/>
<property key="X_lbl" value="168"/>
<property key="Y_obj" value="323"/>
<property key="Y_lbl" value="360"/>
74 Definicion de Redes de Petri en XML
</data-object>
<data-object name="properties"
type="org.cyrano.pnet.mapping.TokenPlace">
<property key="token-cnt" value="1"/>
<property key="token-max" value="2"/>
<property key="token-min" value="0"/>
</data-object>
</place>
De esta forma, se describe un lugar llamado p1 que tiene como fabrica de com-
ponentes a la clase org.cyrano.pnet.plugins.plugins.TokenPlaceFactory. Ademas,
la descripcion del lugar esta formada dos data objects, el primero, llamado aPla-
ceData, que contiene informacion geometrica del mismo (donde dibujarlo) y el
segundo, llamado properties, que contiene la parametrizacion concreta que define
el comportamiento de este lugar en particular. En este caso, el data object pro-
perties especifica que el lugar contiene una ficha y que puede tener un maximo de
dos y un mınimo de cero (token-cnt, token-max y token-min respectivamente).
Un ejemplo que define una transicion:
<transition name="t1"
type="org.cyrano.pnet.plugins.plugins.SimpleTransFactory"
event="evt_A">
<data-object name="aTransData"
type="org.cyrano.pnet.editor.acuarela.ATransData"> ...
</data-object>
<data-object name="default-properties"
type="org.cyrano.pnet.mapping.TransDefaultProperties">
<property key="precedence" value="0"/>
</data-object>
</transition>
A Definicion de Redes de Petri en XML 75
En este caso, no se muestran las propiedades del data object aTransData, ya
que son muy parecidas y cumplen la misma funcion que las de aPlaceData del
ejemplo anterior. Sin embargo, se aprecia el data object default-properties, que de-
be estar presente en todas las transiciones y que ademas debe tener una propiedad
llamada precedence que es de tipo entero y representa el nivel de precedencia de
la transicion (ver seccion 3.2.1).
La descripcion de una arista se muestra a continuacion:
<edge name="edge1"
type="org.cyrano.pnet.plugins.plugins.TokenEdgeFactory"
src="t1" dst="p1">
<data-object name="default-properties"
type="org.cyrano.pnet.mapping.EdgeDefaultProperties">
<property key="inhibitor" value="true"/>
</data-object>
<data-object name="properties"
type="org.cyrano.pnet.mapping.TokenEdge">
<property key="token-weight" value="1"/>
</data-object>
</edge>
De igual forma, en el XML anterior se aprecian los data objects de una arista.
Este caso particular define una arista de fichas (ver seccion 3.4.1), y el peso de
la misma se describe con en el data object properties por medio de la propiedad
entera token-weight. Por otra parte, el data object default-properties debe estar
presente en todos los tipos de aristas y debe contener al menos una propiedad de
tipo booleano llamada inhibitor, esto con el fin de representar arcos inhibidores
(ver seccion 2.2).
Apendice B
Tecnologıas y Terminos mas
Comunes en Java
Termino Java Definicion
Applet Un applet es un programa Java que se ejecuta dentro de un
navegador. Los applets usan una interfaz grafica con el usuario
y pueden tener texto, imagenes, botones, barras de desplaza-
miento y sonido. AWT y SWING son asociados frecuen-
temente con artıculos y tutoriales sobre la construccion de
applets.
AWT AWT (Abstract Window Toolkit), segun sus siglas en ingles,
es un paquete de clases para la creacion de componentes, tales
como botones, menus y barras de desplazamiento para Ap-
plets o aplicaciones independientes (standalone)
.
Java API Java API (Java Application Programing Interface), segun sus
siglas en ingles, es un codigo pre-escrito, organizado en paque-
tes de topicos similares. Todo el API de Java esta incluido en
Java 2 Standart Edition descargable en la pagina de SUN
Microsystems URL: java.sun.com
78 Tecnologıas y Terminos mas Comunes en Java
JavaBeans La arquitectura JavaBeans provee una forma de diseno de
software reusable que puede ser manipulada visualmente en
herramientas de construccion. Los Beans pueden ser simples
como botones o mas complejos como herramientas de acceso
a bases de datos.JFC JFC (Java Foundation Classes) son un juego de componentes
graficos GUI y otros servicios que ayudan a la simplificacion
de desarrollo y despliegue de aplicaciones Internet/Intranet.
Java Native
Interface
(JNI)
JNI es la interfaz de programacion nativa para Java que es
parte del JDK. JNI aloja codigo Java para operar con aplica-
ciones y librerıas escritas en otros lenguajes como C, C++ y
ensamblador. Recomendado solo para usuarios avanzados.
Java Server
Pages (JSP)
Con JSP se pueden crear paginas dinamicas en las cuales se
puede insertar codigo con HTML. Las paginas JSP procesan
formas, realizan calculos, o pueden hacer cualquier cosa que
se pueda escribir en un programa Java.
Java Virtual
Machine
La maquina virtual de Java ejecuta instrucciones que genera
el compilador de Java. Este ambiente de ejecucion o JVM en
la actualidad esta implıcito en varios productos como navega-
dores, sistemas operativos y servidores, entre otros.
JDBC JDBC es un API de Java para la ejecucion de sentencias
SQL.Usando el API de JDBC se puede acceder a casi to-
das las fuentes de datos, desde bases de datos hasta hojas de
calculo o algo mas simple como archivos planos. En J2SE se
incluye el API de JDBC.
JDK JDK es el nombre corto para el conjunto de herramientas de
Java (Java Development Kit), esta constituido por el API, el
compilador, y la maquina virtual que varıan de acuerdo a la
version. El JDK es utilizado para compilar aplicaciones Java
y Applets.
B Tecnologıas y Terminos mas Comunes en Java 79
Jini Jini es una tecnologıa de redes que habilita cualquier servicio
a trabajar fluido y simple en red. La arquitectura permite
a cada servicio (programa o dispositivo) decir a otros como
hablar con el, sin necesidad de ningun administrador.
Swing El paquete de clases javax.swing es usado para crear compo-
nentes graficos (GUI) para Applets o aplicaciones. El proyecto
Swing permite a programadores especificar un tema diferente
para cada plataforma (Look and Feel), o un unico tema para
todas las plataformas. Swing es el nombre del proyecto para
componentes graficos (GUI) de bajo peso en JFC
RMI RMI (Remote Method Invocation) segun sus siglas en ingles,
permite a aplicaciones Java a comunicarse a traves de la red.
Estas aplicaciones pueden estarse ejecutando en diferentes
computadores en lados opuestos del planeta. Este modelo per-
mite el acceso a un objeto remoto tan facil como uno local.
Servlets Los Servlet son una extension JavaTM de un servidor
WEB, con el fin de mejorar su funcionalidad. Los Servlets
comunmente son utilizados para procesar formas, manejar re-
direcciones o autentificar nombres de usuarios y contrasenas,
y crear contenido dinamico.
XClass XClass es una tecnologıa que tienen como objetivo brindar
soporte para manejar y describir meta-objetos, que pueden
ser utilizados de una forma practica y sencilla, por una gran
variedad de aplicaciones.
Acuarela Acuarela es una librerıa desarrollada en JavaTM disenada
para facilitar el desarrollo de aplicaciones que contengan edi-
tores graficos de objetos, herramientas de visualizacion y ani-
maciones en general. Se basa fundamentalmente en el modelo
MVC (Model View Controller).
80 Tecnologıas y Terminos mas Comunes en Java
MBeans MBeans es una librerıa de beans graficos para hacer interfaces
hombre - maquina basadas en tecnologıa Swing de JavaTM.
En general, MBeans pretende resolver y cubrir algunas defi-
ciencias de Swing para facilitar un poco la programacion de
GUI.MinoDB MinoDB es una librerıa desarrollada en JavaTM que hace
posible la persistencia transparente de objetos JavaTM en
una base de datos relacional. La librerıa permite mecanizar
y automatizar todo lo relacionado con el manejo de la base
de datos, de modo que el cliente pueda concentrarse mas en
su aplicacion y menos en el manejo de la persistencia de los
datos.Cuadro B.1: Tecnologıas mas Comunes en Java
Apendice C
Acronimos
API: Application Programming Interface.
EJB: Enterprise Java Beans.
GUI: Graphics User Interface.
JDBC: Java Database Connectivity.
JMS: Java Message Service.
JNDI: Java Naming and Directory Interface.
JNI: Java Native Interface.
JSP: Java Server Pages.
JVM: Java Virtual Machine.
MVC: Model View Controller.
RMI: Remote Method Invocation.
SQL: Structured Query Language.
XML: Extensible Markup Language.
82 Acronimos
Referencias
A.H. Lewis. (1999). An introduction to petri nets.
Eric S. Raymond. (2000). The cathedral and the bazaar.
http://www.tuxedo.org/ esr/writings/cathedral-bazaar/.
Gile, M. R., & DiCesare, F. (*). Toward distributed simulation of complex
discrete event systems represented by colored petri nets: A review.
Harald Storrle. (1998). An evaluation of high-end tools for petri nets.
Janette Cardoso, B. Pradin-Chezalviel. (1997, Jun). Logic and fuzzy petri nets.
A Workshop within the XVIII International Conference on Applications
and Theory of Petri Nets.
Janette Cardoso, Robert Valette. (1997). Redes de petri. Editora da Universidade
Federal de Santa Catarina.
Krzysztof Sacha. (2001, Dec). Fault analysis using petri nets.
Kurt Jensen. (1997). A brief introduction to coloured petri nets. 203-208. Lecture
Notes in Computer Science Vol. 1217, Springer-Verlag.
The petri nets world. (2004). URL: http://www.daimi.au.dk/PetriNets/. (An on-
line database of Petri net-related conferences, mailing lists, bibliographies,
tool databases, newsletters, research groups, etc)
Raskin, J., Tan, Y., & Torre, L. van der. (1996). How to model normative
behavior in petri nets.
Robert Esser. (1996). An object oriented petri net approach to embedded system
design. Unpublished doctoral dissertation.
Robert Valette, Brigitte Pradin-Chezalviel, Francois Girault. (*). An introduction
to petri net theory.
Valette, R. (1997). Some issues about petri net application to manufacturing and
process supervisory control. In ICATPN (p. 23-41).