Contrairement à la génération de code que nous avons présentée au chapitreV, la traduction en réseau de Petri rend compte des flux d’exécution. Selon cette approche, chaque sous-programme est modélisé dans le réseau autant de fois qu’il est appelé. Chaque appel de sous-programme est donc assimilé à une instance. Il en est par conséquent de même pour un accès requis à un sous- programme.
Règle VII.12 (Traduction des accès à sous-programme)
L’appel d’un sous-programme dont l’accès est requis par un thread ou un sous- programme est assimilé à un appel normal au sous-programme correspondant.
De la même façon que les composants de haut niveau, les sous-programmes sont modélisés par une transition entourée de places modélisant les paramètres d’entrée et de sortie.
Règle VII.13 (Traduction des sous-programmes)
Un appel de sous-programme AADL est traduit par une transition et des places cor- respondant à ses différents paramètres. Le flux d’exécution contrôlant l’appel du sous- programme est matérialisé par deux places transmettant un jeton de contrôle à la transi- tion du sous-programme. Ce jeton de contrôle est celui du thread dans lequel l’appel est effectué.
Les places d’entrée sont connectées à la transition du sous-programme par un arc simple, de la même façon que pour les places de contrôle. Les places de sortie ont un marquage initial fixé à u. La transition du sous-programme consomme et réinjecte les jetons issus de ces places. Une garde est associée à la transition pour empêcher la consommation de la valeur indéfinie u.
Un paramètre d’entrée sortie est traduit par une place d’entrée et une place de sortie.
Les paramètres de sortie des sous-programmes modélisent des variables : leur valeur doit pou- voir être lue plusieurs fois, par différents sous-programmes. C’est pourquoi la transition du sous- programme doit remplacer un jeton qui est constamment à disposition.
Le cas d’un appel à un sous-programme distant – dont l’accès est fourni par un autre thread – présente quelques spécificités. En effet, un tel sous-programme met en jeu à la fois le thread local, qui effectue l’appel, et le thread distant, qui exécute effectivement le sous-programme. L’exécution du sous-programme nécessite donc les ressources d’exécution des deux threads.
Règle VII.14 (Traduction des appels de sous-programme distant)
Un appel de sous-programme distant est modélisé comme un appel de sous-programme local en ajoutant une paire de places de contrôle ; ces places correspondent au thread fournissant le sous-programme.
Un appel de sous-programme distant possède donc deux places d’entrée pour les jetons de contrôle : l’une correspondant au jeton de contrôle du thread local, l’autre recevant le jeton de contrôle du thread distant.
VII-5.2.1 Modélisation des connexions des paramètres
Les connexions de paramètres doivent laisser les jetons de donnée à la disposition d’éven- tuelles autres connexions.
Règle VII.15 (Traduction des connexions de paramètres)
L’ensemble des connexions dirigée vers un appel de sous-programme donné est traduit par une unique transition. Cette transition consomme et réinjecte les jetons issus des places correspondant aux paramètres de sortie des appels de sous-programme situés en amont dans la séquence d’appels. Elle consomme également le jeton de contrôle destiné à l’appel de sous-programme.
Elle distribue l’ensemble de ces jetons aux places d’entrée du sous-programme.
De la même façon que les connexions de ports de donnée, les connexions de paramètres consomment et réinjectent les jetons de donnée. Elles centralisent l’ensemble des jetons desti- nés au sous-programme destinataire. Cette synchronisation permet de limiter les états possibles au sein du réseau de Petri. En effet, dans la mesure où la transition d’une connexion consomme et réinjecte les jetons issus des places de sortie des sous-programmes amonts, il est nécessaire de synchroniser leur déclenchement avec le jeton de contrôle d’exécution, qui est consommé norma- lement. Nous évitons ainsi la création d’états artificiels liés au fait qu’une transition réinjectant le jeton consommé peut toujours être déclenchée.
<v> <v> <v> <v> <v2> <c> <c> <v> <v> <c> <v> <c> <c> <c> [v <> u] sp1_sp2 Class Value is ["u", "d"]; Control is 1 .. 1; Var v, v2 in Value; c in Control; Value <u> sp1_s Value sp2_e sp1 Control sp1_c_s Control sp2_c_e sp2 sp2_s Value Value <d> sp1_e Control 1 sp1_c_e Control sp2_c_s
FIG. VII.6 – Réseau de Petri d’une connexion entre deux sous-programmes
Le réseau de Petri de la figureVII.6illustre une connexion entre deux sous-programmes (sp1
L’ensemble des connexions entre les paramètres des sous-programmes est rassemblé dans une seule transition, que nous appelonssp1_sp2 d’après les deux appels de sous-programme qu’elle
connecte. Cette transition prend en charge à la fois la connexion AADL entre les paramètres des sous-programmes et la circulation du jeton de contrôle. La place de sortiesp1_sest initialisée à
une valeur invalide (u), qui ne peut pas franchir la connexionsp1_sp2. Ce jeton de valeur invalide
modélise le fait qu’à l’état initial, la valeur de sortie de sp1 est indéterminée. Lorsque le sous-
programmesp1produit un résultat, le jeton du résultat remplace le jeton invalide et peut donc être
transmis au sous-programmesp2. La valeur de sortie stockée danssp1_scorrespond correspond à
une variable, et doit donc pouvoir être lue plusieurs fois. C’est pourquoi le jeton est réinjecté dans la placesp1_slorsqu’il traverse la transitionsp1_sp2.