[Pour la version PDF de cette réponse , les figures ou les diagrammes sont interactifs et dynamiques.]
Éléments nets et annotations: langage de programmation visuel polyvalent
J'utilise des graphiques pour organiser les programmes JavaScript ™ utilisant l'API Acrobat® / JavaScript. Chaque objet graphique représente un élément du réseau de Petri (lieu, transition, entrée ou sortie) ou représente plusieurs éléments du réseau de Petri. Chaque objet graphique est en fait une annotation de l'élément net correspondant. Cependant, si chaque objet graphique correspond à un et un seul élément net, il peut être utilisé pour générer l'élément net. Et si un objet graphique est mappé sur plusieurs éléments du réseau et que la mise en correspondance est bien définie, il peut également être utilisé pour générer les éléments du réseau. Les éléments standard du réseau de Petri sont représentés par certains types de graphiques: un cercle est un endroit, un carré ou un rectangle ou une ligne est une transition, une flèche d'un cercle à un carré est une entrée et une flèche d'un carré à un cercle est une sortie. En outre,
[Les types d'annotations dans un "réseau de Petri standard" figurent dans la version PDF de cette réponse.]
Carl Adam Petri a décrit la plupart de ces idées (y compris les types d'annotations dans un "réseau de Petri standard" dans sa thèse de doctorat (Petri, 1966). Il a également appliqué les éléments de réseau et les annotations à la description de plusieurs circuits logiques, tels que la Figure 6
Avantages et défis
Un langage de programmation visuel peut aider un programmeur informatique à développer des programmes informatiques (Menzies, 2002).
J'ai au moins trois raisons pour lesquelles je trouve les éléments nets et les annotations utiles (avantages?).
Première raison. La logique de processus peut être créée un élément à la fois. Cela signifie qu'un réseau peut être étendu en ajoutant des éléments au réseau existant (Petri, 1966). Par exemple, un modèle de contrôleur peut être divisé en composants internes et externes. Le composant interne régule le système. Le composant externe s'interface avec l'environnement en acceptant les entrées de l'environnement. La figure 1 est un modèle de Petri Net du composant interne. Il est possible d'ajouter un modèle Net du réseau de Petri du composant externe au modèle Net du réseau de Petri en ajoutant les emplacements et la transition appropriés (Figure 2).
Figure 1 Modèle de réseau de Petri d'une composante interne d'un contrôleur (Halloway, Krogh et Giua, 1997)
Figure 2 Modèle de réseau de Petri des composants internes et externes d'un contrôleur (Halloway, Krogh et Giua, 1997)
Deuxième raison. Les codes associés à chaque élément du réseau peuvent provenir de plus d’un «langage de programmation» (Petri, 1973). Ils peuvent provenir d'un langage informatique tel que JavaScript, COBOL, ADA et d'un langage d'assemblage. Ils peuvent provenir d'un langage mathématique tel que les symboles algébriques. Ils peuvent provenir de textes codés en anglais, allemand, français, grec, tagalog, chinois, etc. Ils peuvent donc servir de base à la communication et à la collaboration tout au long du cycle de vie du développement du logiciel ou du système; et parmi différents utilisateurs, développeurs et parties prenantes (Petri, 1973).
Troisième raison. Il est possible de se concentrer sur certains objets graphiques du réseau et d’écrire le code ou les annotations logiques des objets graphiques associés. Prenons un modèle de Petri Net d’un jeu de cartes illustré à la figure 3. Si la flèche pour l’entrée P7 T4 est un graphique standard pour une entrée dans un lieu / réseau de transition et si m_7 est le repère de l’emplacement P7, alors l’annotation logique pour la mise à jour de la marque du lieu d'entrée est m_7 = m_7-1. Si s_9 ^ - est le statut de l'entrée, l'annotation logique permettant de mettre à jour le statut de l'entrée est s_9 ^ - = ((m_7 <1)? False: vrai).
Figure 3 Un modèle de jeu de cartes Net Petri
J'ai au moins trois raisons pour lesquelles je trouve l'application des réseaux de Petri difficile (inconvénients?)
S'il y a trop d'objets graphiques, il sera difficile de créer ou de lire le net. La difficulté peut être atténuée en prenant un sous-ensemble des graphiques et en les représentant en utilisant un, deux ou trois symboles graphiques (Noe, 1973; Petri, 1966). Par exemple, si le modèle de jeu de cartes Petri Net de la figure 3 est considéré comme comportant trop d'objets graphiques dans le diagramme, il est possible de combiner une partie des graphiques tout en conservant suffisamment d'informations pour que le diagramme puisse être mappé dans un programme informatique. Prenons l'exemple de la figure 4, un modèle de Petri Net du même jeu que celui de la figure 3 avec des graphiques de haut niveau (Chionglo, 2016a).
Figure 4 Modèle de réseau de Petri d'un jeu de cartes utilisant des graphiques de haut niveau (Chionglo, 2016a)
Dans un autre exemple, les composants externes du contrôleur de la figure 2 peuvent être combinés pour créer une représentation graphique plus concise, comme illustré à la figure 5.
Figure 5 Modèle de réseau de Petri d'un contrôleur avec graphiques de haut niveau pour composants externes
Enfin, un ensemble de lieux mutuellement exclusifs ou un ensemble de transitions mutuellement exclusifs peut également être représenté à l'aide d'un objet graphique de haut niveau (Chionglo, 2015).
Deuxième raison. Même avec des graphiques standard, il peut être difficile de dessiner et de positionner des graphiques, en particulier si l'on s'attend à ce que le diagramme final soit convivial ou lisible. Parmi les décisions à prendre pour créer un diagramme convivial pour l'utilisateur ou le lecteur, citons: la disposition correcte des objets graphiques, les dimensions appropriées du canevas et des formes, la courbure des flèches, le type de têtes de flèches, la taille et la police du texte, et le choix des couleurs pour les graphiques et le texte.
Troisième raison. Il est facile de créer des annotations d’éléments du réseau de manière ordonnée car chaque annotation est directement ou indirectement liée à un élément du réseau. Cependant, l'affichage de chaque annotation avec les graphiques de chaque élément de réseau peut ne pas être une bonne idée car il pourrait y avoir trop d'informations présentées dans le diagramme. Par exemple, considérons le schéma d’un modèle de réseau de Petri d’un circuit logique incluant des références à toutes les annotations de propriété et de logique (Figure 6). [Le modèle d'origine incluait une condition de test pour le statut de pour chaque sortie (figure 31, page 78 de (Petri, 1966)); la condition de test a été omise ici car elle est équivalente au modèle d'origine pour le marquage initial donné. Ainsi, chaque sortie a une annotation logique pour calculer la marque de la place de sortie.]
Figure 6 Un lieu / réseau de transition avec annotations - basé sur la figure 31, page 78 d'une traduction anglaise de la thèse de Petri (1966)
Une façon de résoudre ce problème serait d'identifier les types d'annotations utilisés dans le modèle et de définir des objets graphiques qui incluent des annotations de ce type (Petri, 1966). Ainsi, lorsqu'un diagramme de Petri Net est composé d'objets graphiques issus des définitions, l'interprétation de ces objets doit inclure les annotations «invisibles». La Figure 7 doit être interprétée comme un réseau de Petri standard (voir les annotations d'un réseau de Petri standard pour les définitions); par conséquent, l'annotation logique peut être omise du diagramme.
Figure 7 Un lieu / réseau de transition - d'après la figure 31, page 78 d'une traduction anglaise de la thèse de Petri (1966)
Un autre moyen d'atténuer ce problème serait d'utiliser des vues de formulaire des annotations pour compléter ou compléter le (s) diagramme (s) (Chionglo, 2016b; 2014). Les vues peuvent être divisées en vues plus petites et chaque vue peut être affichée et masquée.
Les références
Chionglo, JF (2016a). Une réponse à “Comment concevoir un flux d’états pour un jeu de cartes flash réactif / redux?” Dans Stack Overflow. Disponible à l' adresse 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). Deux vues de formulaire d'un réseau de Petri. Disponible à http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .
Chionglo, JF (2015). Réduire le nombre de graphiques d'éléments nets dans un diagramme de Petri Net à l'aide de graphiques de haut niveau. Disponible à http://www.aespen.ca/AEnswers/WjTpY1429533268 .
Chionglo, JF (2014). Éléments nets et annotations pour la programmation informatique: calculs et interactions en PDF. Disponible à l' adresse https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .
Halloway, LE; Krogh, BH et Giua, A. (1997). Enquête sur les méthodes de Petri Net pour les systèmes à événements discrets contrôlés [version électronique]. Systèmes dynamiques à événements discrets: théorie et applications, vol. 7. Boston: Kluwer Academic Publishers, p. 151 - 190.
Menzies, T. (2002). Problèmes d'évaluation pour les langages de programmation visuels. Dans SK Chang (Ed). Manuel de génie logiciel et d'ingénierie du savoir, vol. 2 Technologies émergentes. World Scientific Publishing co. Pte. Ltd., p. 93 - 101.
Noe, JD et Nutt, GJ (1973). «Macro E-Nets pour la représentation de systèmes parallèles», IEEE Transactions on Computers, vol. C-22, n ° 8, août 1973, p. 718 - 727.
Petri, CA (1973). Concepts de la théorie du réseau. Dans les fondements mathématiques de l'informatique: Proc. du symposium et des cours d’été, Hautes Tatras, du 3 au 8 septembre 1973, pages 137 à 146. Math. Inst. de la Slovaque Acad. des sciences, 1973.
Petri, CA (1966). Communication avec Automota [trans. CF Greene, Jr.]. Supplément I au rapport technique RADC-TR-65-377 (volume I). Base aérienne Griffiss, NY: Centre de développement aérien de Rome, Division de la recherche et de la technologie, Commandement des systèmes de la Force aérienne, Base aérienne de Griffiss. Extrait le 31 août 2011 sur http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .