[Para la versión PDF de esta respuesta , las figuras o diagramas son interactivos y dinámicos.]
Elementos netos y anotaciones: un lenguaje de programación visual de uso general
Utilizo gráficos para organizar programas JavaScript ™ que usan la API Acrobat® / JavaScript. Cada objeto gráfico representa un elemento de Petri Net (lugar, transición, entrada o salida) o representa más de un elemento de Petri Net. Cada objeto gráfico es en realidad una anotación del elemento neto correspondiente. Sin embargo, si cada objeto gráfico se asigna a un solo elemento neto, se puede usar para generar el elemento neto. Y si un objeto gráfico se asigna a más de un elemento de red y la asignación está bien definida, entonces también se puede usar para generar los elementos de red. Los elementos estándar de la red de Petri están representados por ciertos tipos de gráficos: un círculo es un lugar, un cuadrado o rectángulo o línea es una transición, una flecha de un círculo a un cuadrado es una entrada y una flecha de un cuadrado a un círculo es un salida. Además,
[Los tipos de anotaciones en una "Red estándar de Petri" se encuentran en la versión PDF de esta respuesta.]
Carl Adam Petri describió la mayoría de estas ideas (incluidos los tipos de anotaciones en una "Red estándar de Petri" en su disertación doctoral (Petri, 1966). También aplicó los elementos netos y las anotaciones a la descripción de varios circuitos lógicos, como la Figura 6)
Beneficios y desafíos
Un lenguaje de programación visual puede ayudar a un programador informático a desarrollar programas informáticos (Menzies, 2002).
Tengo al menos tres razones por las que encuentro útiles las anotaciones y los elementos netos (¿ventajas?).
La primera razón. La lógica del proceso se puede crear un elemento a la vez. Esto significa que una red puede extenderse agregando elementos a la red existente (Petri, 1966). Por ejemplo, un modelo de controlador puede dividirse en componentes internos y externos. El componente interno regula el sistema. El componente externo interactúa con el entorno al aceptar la entrada del entorno. La Figura 1 es un modelo de Petri Net del componente interno. Es posible agregar un modelo de Petri Net del componente externo al modelo de Petri Net del componente interno agregando los lugares y la transición apropiados (Figura 2).
Figura 1 Un modelo de red de Petri de un componente interno de un controlador (Halloway, Krogh y Giua, 1997)
Figura 2 Un modelo de red de Petri de componentes internos y externos de un controlador (Halloway, Krogh y Giua, 1997)
Segunda razón. Los códigos asociados con cada elemento neto pueden provenir de más de un "lenguaje de programación" (Petri, 1973). Pueden provenir de un lenguaje de computadora como JavaScript, COBOL, ADA y un lenguaje ensamblador. Pueden provenir de un lenguaje matemático como los símbolos algebraicos. Pueden provenir de prosa codificada en inglés, alemán, francés, griego, tagalo, chino, etc. Por lo tanto, se puede utilizar como base para la comunicación y la colaboración a lo largo del ciclo de vida de desarrollo de software o sistema; y entre diferentes usuarios, desarrolladores y partes interesadas (Petri, 1973).
Tercera razón Es posible centrarse en ciertos objetos gráficos en la red y escribir el código o las anotaciones lógicas para los objetos gráficos relacionados. Considere un modelo de Petri Net de un juego de cartas en la Figura 3. Si la flecha para la entrada P7 T4 es un gráfico estándar para una entrada en una Red de Lugar / Transición y si m_7 es la marca para el lugar P7, entonces la anotación lógica para actualizar la marca del lugar de entrada es m_7 = m_7-1. Si s_9 ^ - es el estado de la entrada, entonces la anotación lógica para actualizar el estado de la entrada es s_9 ^ - = ((m_7 <1)? Falso: verdadero).
Figura 3 Un modelo de Petri Net de un juego de cartas
Tengo al menos tres razones por las que encuentro desafiante la aplicación de redes de Petri (¿desventajas?)
Si hay demasiados objetos gráficos, sería difícil crear o leer la red. La dificultad puede mitigarse tomando un subconjunto de los gráficos y representándolos con uno, dos o tres símbolos gráficos (Noe, 1973; Petri, 1966). Por ejemplo, si se considera que el modelo Petri Net de un juego de cartas en la Figura 3 tiene demasiados objetos gráficos en el diagrama, es posible combinar algunos de los gráficos y aún mantener suficiente información para mapear el diagrama en un programa de computadora. Considere la Figura 4, un modelo de Petri Net del mismo juego que se encuentra en la Figura 3 con gráficos de alto nivel (Chionglo, 2016a).
Figura 4 Un modelo de Petri Net de un juego de cartas con gráficos de alto nivel (Chionglo, 2016a)
En otro ejemplo, los componentes externos del controlador en la Figura 2 se pueden combinar para crear una representación gráfica más concisa como se muestra en la Figura 5.
Figura 5 Un modelo de red de Petri de un controlador con gráficos de alto nivel para componentes externos
Finalmente, un conjunto de lugares mutuamente excluyentes o un conjunto de transiciones mutuamente excluyentes también pueden representarse utilizando un objeto gráfico de alto nivel (Chionglo, 2015).
Segunda razón. Incluso con gráficos estándar, puede ser difícil dibujar y colocar gráficos, especialmente si se espera que el diagrama final sea fácil de usar o leer. Algunas de las decisiones para hacer un diagrama amigable para el usuario o el lector incluyen: la disposición adecuada de los objetos gráficos, las dimensiones apropiadas del lienzo y las formas, la curvatura de las flechas, el tipo de puntas de flecha, el tamaño y la fuente del texto, y la elección de colores para gráficos y texto.
Tercera razón Es fácil crear anotaciones de elementos netos de manera ordenada porque cada anotación está directa o indirectamente relacionada con un elemento neto. Sin embargo, mostrar cada anotación junto con los gráficos de cada elemento neto puede no ser una buena idea porque podría haber demasiada información presentada en el diagrama. Por ejemplo, considere un diagrama de un modelo de red de Petri de un circuito lógico que incluye referencias a todas las propiedades y anotaciones lógicas (Figura 6). [El modelo original incluía una condición de prueba para el estado de cada salida (figura 31 en la página 78 de (Petri, 1966)); aquí se omitió la condición de prueba porque es equivalente al modelo original para la marca inicial dada. Por lo tanto, cada salida tiene una anotación lógica para calcular la marca del lugar de salida.]
Figura 6 Una red de lugar / transición con anotaciones: basada en la figura 31, página 78, de una traducción al inglés de la disertación de Petri (1966)
Una forma de mitigar este desafío sería identificar los tipos de anotaciones utilizadas en el modelo y definir objetos gráficos que incluyan anotaciones de estos tipos (Petri, 1966). Así, cuando un diagrama de Petri Net se compone de objetos gráficos de las definiciones, la interpretación de estos objetos debe incluir las anotaciones "invisibles". La figura 7 debe interpretarse como una red de Petri estándar (consulte las anotaciones de una red de Petri estándar para obtener las definiciones); por lo tanto, la anotación lógica puede omitirse del diagrama.
Figura 7 Una red de lugares / transición: basada en la figura 31, página 78 de una traducción al inglés de la disertación de Petri (1966)
Otra forma de mitigar este desafío sería utilizar vistas de formulario de las anotaciones para complementar o complementar los diagramas (Chionglo, 2016b; 2014). Las vistas pueden dividirse aún más en vistas más pequeñas, y cada vista puede mostrarse y ocultarse.
Referencias
Chionglo, JF (2016a). Una respuesta a "¿Cómo diseñar un flujo de estado para un juego flashcard react / redux?" En Stack Overflow. Disponible en https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .
Chionglo, JF (2016b). Dos vistas de una red de Petri. Disponible en http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .
Chionglo, JF (2015). Reducir el número de gráficos de elementos netos en un diagrama de red de Petri utilizando gráficos de alto nivel. Disponible en http://www.aespen.ca/AEnswers/WjTpY1429533268 .
Chionglo, JF (2014). Elementos netos y anotaciones para la programación de computadoras: cálculos e interacciones en PDF. Disponible en https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .
Halloway, LE; Krogh, BH y Giua, A. (1997). Una encuesta de los métodos de Petri Net para sistemas controlados de eventos discretos [versión electrónica]. Sistemas dinámicos de eventos discretos: teoría y aplicaciones, vol. 7. Boston: Kluwer Academic Publishers, págs. 151-190.
Menzies, T. (2002). Problemas de evaluación para lenguajes de programación visual. En SK Chang (Ed). Manual de Ingeniería de Software e Ingeniería del Conocimiento, vol. 2 Tecnologías emergentes. World Scientific Publishing co. Pte. Ltd., pp. 93-101.
Noe, JD y Nutt, GJ (1973). "Macro E-Nets para la representación de sistemas paralelos", IEEE Transactions on Computers, vol. C-22, N ° 8, agosto de 1973, págs. 718 - 727.
Petri, CA (1973). Conceptos de teoría de redes. En Fundamentos matemáticos de la informática: Proc. of Symposium and Summer School, High Tatras, del 3 al 8 de septiembre de 1973, páginas 137 - 146. Matemáticas. Inst. del Acad eslovaco. de Ciencias, 1973.
Petri, CA (1966). Comunicación con Automota [trans. CF Greene, Jr.]. Suplemento I al Informe técnico RADC-TR-65-377 (Volumen I). Base de la Fuerza Aérea Griffiss, NY: Centro de Desarrollo Aéreo de Roma, División de Investigación y Tecnología, Comando de Sistemas de la Fuerza Aérea, Base de la Fuerza Aérea Griffiss. Recuperado el 31 de agosto de 2011 de http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .