IX- 2.6 Intégration dans la démarche MDA
VII.7 Modélisation de séquences d’appel, correspondant au listing VII.3
21 thread thread_b
22 features
23 rpc : requires subprogram access sspg_b;
24 e1 : in event data port donnee;
25 s1 : out event data port donnee;
26 s2 : out event data port donnee;
27 end thread_b;
28
29 thread implementation thread_b.impl
30 calls
31 seq1 : {appel1 : subprogram sspg_a;
32 appel2 : subprogram sspg_b;};
33 seq2 : {appel3 : subprogram access rpc;};
34 connections
35 cnx1 : parameter e1 -> appel1.e1;
36 cnx2 : parameter e1 -> appel3.e1;
37 cnx3 : parameter e1 -> appel3.e2;
38 cnx4 : parameter appel1.s1 -> appel2.e1;
39 cnx5 : parameter appel3.s1 -> appel2.e2;
40 cnx6 : parameter appel3.s1 -> s1; 41 cnx7 : parameter appel2.s1 -> s2; 42 end thread_b.impl; 43 44 process processus 45 features
46 e : in event data port donnee;
47 s : out event data port donnee;
48 end processus;
49
50 process implementation processus.impl
51 subcomponents
52 thread1 : thread thread_a;
53 thread2 : thread thread_b.impl;
54 connections
55 subprogram access thread1.rpc -> thread2.rpc;
56 event data port e -> thread2.e1;
57 event data port thread2.s1 -> s;
58 end processus.impl;
Listing VII.3 – Appels de sous-programmes, traduits en réseau de Petri sur la figureVII.7 Le second thread,thread2comporte deux séquences d’appel. La première est constituée de
deux appels de sous-programmes ; la seconde est en fait un appel distant au sous-programme fourni par le premier thread,thread1. La circulation des données, indiquée par les connexions, est
la suivante :
– appel1effectue un calcul à partir dee1et transmet le résultat àappel2;
– appel3(exécuté sur le premier thread) effectue un calcul à partir dee1et transmet le résultat
àappel2ainsi qu’à la sorties2du second thread ;
– appel2utilise les données fournies parappel1etappel3et renvoie le résultat vers la sortie s1du thread.
Les identificateurs de place et de transition sont construits par concaténation des identificateurs des différentes conteneurs des entités AADL. Ainsithread2_appel1_s1est issu de la features1de
du processus et du système global.
Nous retrouvons les éléments de la description de haut niveau des threads : les transitions
thread2_begin etthread2_endcorrespondent à la transition de traitement du thread, les places thread2_c_beginetthread2_c_enddemeurent celles de la modélisation de haut niveau, de même
que la transitionthread2_init. Il en est de même pourthread1.
Les deux séquences d’appels dethread2sont délimitées par des transitions beginetend; il
s’agit du même principe que pour les transitions encadrant le contenu des threads. La transition
thread2_appel1_appel2permet de connecter les deux appels de sous-programmethread2_appel1
etthread2_appel2; elle centralise les différentes connexions AADL vers les paramètres de l’appel thread2_appel2.
VII-6 Intégration des descriptions comportementales
Comme nous l’avons expliqué au chapitre III, AADL décrit les aspects architecturaux des systèmes, c’est-à-dire principalement l’agencement des composants ; les aspects algorithmiques sont en dehors du cadre des modélisations. De la même façon que pour la génération de code (cf. chapitreV) une description comportementale des composants en réseau de Petri doit pouvoir être fournie ; elle doit correspondre à l’implantation en code source. Par conséquent, seuls les sous-programmes peuvent avoir une telle description comportementale. De la même façon qu’au chapitreV, nous distinguons quatre cas de sous-programmes :
VII-6.1 Composant sans modélisation comportementale
En l’absence d’éléments complémentaires, la modélisation d’un composant est celle que nous avons décrite en sectionVII-4.
Règle VII.20 (Traduction d’un composant sans modélisation comportementale) Un composant sans modélisation comportementale est traduit par une simple transition. VII-6.2 Composant possédant une description comportementale
Dans le cas d’un composant simple, l’introduction d’une modélisation comportementale consiste à substituer la transition centrale par le réseau de Petri modélisant le comportement du composant.
Règle VII.21 (Traduction d’un composant dont l’implantation est opaque)
Le sous-réseau de Petri modélisant le comportement d’un sous-programme doit compor- ter une place de départbeginet une place de finend.
La transition représentant le corps du sous-programme composant est transformée en deux transitions composant_begin et composant_end. composant_begin est reliée à la
placebegin; la placeendest reliée à la transitioncomposant_end.
Le sous-réseau comportemental doit faire apparaître les différentes places corres- pondant aux paramètres du sous-programme ; ces places sont reliées aux transitions
composant_beginetcomposant_end.
Le réseau de Petri de la modélisation comportementale des composants doit faire apparaître les places initiales et finales. De cette façon, il est possible de fusionner les places contenues dans la description comportementale avec celles générées automatiquement à partir de la description AADL. La description fournie par l’utilisateur doit reprendre les noms de places utilisées dans la description AADL.
VII-6.3 Séquence d’appel pure
Dans le cas où un composant (sous-programme ou thread) est constitué seulement d’une sé- quence d’appel, nous considérons que cette séquence décrit complètement le comportement du composant – nous suivons donc les mêmes hypothèses que pour la génération de code. Le réseau de Petri issu de la séquence constitue alors la description comportementale du composant. VII-6.4 Composant hybride
Lorsque la description AADL d’un composant comporte plusieurs séquences d’appel, toutes les combinaisons d’exécutions sont possibles. Contrairement à la génération de code, qui génère les séquences possibles mais n’en exécute aucune par défaut, nous avons vu en sectionVII-5.3que la traduction en réseau de Petri permet de représenter tous les scénarios d’exécutions possibles.
Dans un cas comme dans l’autre, il est nécessaire d’adjoindre une description comportemen- tale pour indiquer dans quel ordre et sous quelles conditions les séquences doivent s’exécuter.
Le réseau de Petri comportemental décrit alors la circulation du jeton de contrôle à travers les séquences. Afin de pouvoir en effectuer un traitement automatique, les places et les transitions du réseau comportemental doivent respecter certaines règles de nommage :
Règle VII.22 (Descriptions comportementales pour les sous-programmes hybrides) La description de l’enchaînement des séquences d’appel à exécuter est constituée d’un réseau de Petri dont la première place doit s’appelerbeginet la dernière placeend. Les
séquences d’appel qui doivent être exécutée sont représentées par des transition dont le nom correspond au nom AADL des séquences à coordonner.
La description complète du composant s’obtient par fusion des transitions avec les sous- réseaux des séquences.
Règle VII.23 (Coordination des séquences d’appel)
La coordination des séquences d’appel d’un sous-programme composantest effectuée
par la fusion des transitions de la description comportementale avec les séquences cor- respondantes. Les placesbeginetenddu réseau comportemental sont reliées aux transi-
tionscomposant_beginetcomposant_end.
Les transitionscomposant_beginetcomposant_endont été définies dans la règleVII.17.
1 subprogram sspg_a 2 features 3 e : in parameter; 4 end sspg_a; 5 6 subprogram sspg_b 7 features 8 e : in parameter; 9 calls
10 seq1 : {appel1 : subprogram sspg_a;};
11 seq2 : {appel2 : subprogram sspg_a;};
12 connections
13 parameter e -> appel1.e;
15 end sspg_b;
Listing VII.4 – Description d’un sous-programme avec deux séquences d’appel, correspondant au réseau de Petri de la figureVII.8(a)
Le listingVII.4 décrit un sous-programme possédant deux séquences d’appelseq1 etseq2.
Chaque séquence appelle un seul sous-programme, qui prend un paramètre en entrée et ne rend rien en sortie. La traduction en réseau de Petri est illustrée sur la figureVII.8(a). Nous voyons que les deux séquences peuvent s’exécuter dans un ordre arbitraire, un nombre quelconque de fois.
La figureVII.8(b)modélise le comportement que nous souhaitons appliquer au sous-programme : nous voulons d’abord exécuter la séquenceseq1puis la séquenceseq2, puis terminer l’exécution
du sous-programme.
La figure VII.8(c) est le résultat de la fusion du réseau issu de la description AADL et du réseau comportemental. Nous voyons que les transitions seq1 et seq2 sont fusionnées avec les
sous-réseaux de séquences correspondantes ; les placesbeginetendsont connectée à la transition
initpour que le réseau du sous-programme puisse contrôler le sous-réseau comportemental.
VII-7 Propriétés étudiées sur l’architecture
La traduction d’une modélisation AADL en réseau de Petri permet d’extraire les flux d’exé- cution et de les représenter dans un formalisme facilitant leur analyse. Il est possible d’utiliser les formules de logique temporelle afin de vérifier certains comportements sur l’architecture com- plète. Ces vérifications sont spécifiques à la modélisation considérée, et notamment dépendent a priorides modélisations comportementales fournies pour les différents composants.
Parallèlement, la vérification de certaines caractéristiques de l’architecture peut être effectuée systématiquement. Ces vérifications concernent des propriétés structurelles concernant la viabilité des flux d’exécution ; par exemple, nous voulons systématiquement nous assurer que la construc- tion architecturale ne fait pas apparaître de blocage dans les flux d’exécution.
Le réseau de Petri généré à partir d’une description AADL modélise la circulation des données et des flux d’exécution. Nous pouvons donc l’exploiter afin d’analyser les éventuels dysfonction- nements dans l’exécution de l’architecture.
Un dysfonctionnement dans l’architecture correspond à un arrêt de la circulation des données, et peut se manifester de plusieurs façons :
– les communications entre les différents threads ne sont pas coordonnées ; – l’absence d’une donnée dans l’exécution des séquences d’un thread ; – la « famine » d’un thread ;
– le blocage de l’exécution d’un thread ;
– l’utilisation de données dont la valeur n’est pas déterministe.
L’apparition de ces situations dans l’architecture peut être traduite par des propriétés struc- turelles sur le réseau ou des formules de logique temporelle. Dans la suite nous présentons les différentes formules correspondantes.
VII-7.1 Cohérence des communications
Nous avons vu en sectionVII-4.2.3que les réseaux de Petri que nous construisons sont censés être bornés. Certaines configurations architecturales conduisent cependant à une surproduction de jetons qui ne peut pas être régulée par la boucle de rétroaction. Le listing VII.5est un exemple d’une telle configuration ; la figureVII.9représente de réseau de Petri correspondant.
<c> <c> <c> <v> <v> <v> <v> <v> <c> <c> <c> <v> <c> <c> <c> <c> <v> <v> <c> <c> <v> <c> <c> <v> <c> <c> seq1_begin seq2_begin seq1_end seq2_end appel1 appel2
(a) réseau de Petri correspondant au listingVII.4
<c> <c> <c> <c> mid end seq2 seq1 begin 1 (b) réseau de Petri de coordina- tion <c> <c> <c> <c> <c> <c> <c> <c> <c> <c> <c> <c> <c> <v> <v> <v> <v><v> <c> <c> <c> <v> <c> <c> <c> <c> <v> <v> <c> <c> <v> <c> <c> <v> <c> <c> end mid <1> begin appel2 appel1 loop seq2_end seq1_end seq2_begin seq1_begin
(c) réseau de Petri final