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 cuadros

B.1. Tecnologıas mas Comunes en Java . . . . . . . . . . . . . . . . . . 80

ix

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


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.


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:


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.


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


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


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


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.


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.


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.


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


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


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


(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>

</transition>

...

<edge name = "..." type = "..." src = "..." dst = "...">



</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).


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


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.


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 = "...">


<property key = "..." value = "..."/>

...

</data-object>

...

</place>

...

<transition name = "..." type = "..." event = "...">



...

</data-object>

72 Definicion de Redes de Petri en XML

...

</transition>

...

<edge name = "..." type = "..." src = "..." dst = "...">



...

</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"/>


</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).

MOTORDEEJECUCION¶ DEREDESDEPETRI · y ejecutar redes de Petri, de modo que ¶estas puedan...

Documents

Transcript of MOTORDEEJECUCION¶ DEREDESDEPETRI · y ejecutar redes de Petri, de modo que ¶estas puedan...