La figureVII.2résume les différentes modélisations en réseaux de Petri, correspondant aux déclarations du listingVII.1.
donnee (a) donnée <c> <c> <c> <c> thread e_1 s_1 e_2 <1> Control
(b) thread périodique, apé- riodique ou sporadique <c> <c> <2> Control e_2 s_1 e_1 thread (c) thread en tâche de fond
FIG. VII.2 – Modélisation en réseaux de Petri de composants AADLi, décrit au listingVII.1
1 data donnee
2 end donnee;
3
4 thread thread1
5 features
6 e_1 : in data port;
7 e_2 : in event data port;
8 s_1 : out data port;
9 properties 10 Dispatch_Protocol => perdiodic; 11 end thread1; 12 13 thread thread2 14 features
15 e_1 : in data port;
16 e_2 : in event data port;
17 s_1 : out data port;
18 properties
19 Dispatch_Protocol => background;
20 end thread2;
Listing VII.1 – Exemples de déclarations de composants AADL, traduites en réseaux de Petri sur la figureVII.2
VII-4.1.1 Traduction des composants de donnée
Nous distinguons les composants de données des autres composants logiciels. Règle VII.4 (Traduction des composants de donnée)
Une instance de composant de donnée est traduite par une place.
Nous sommes ainsi cohérents avec la règleVII.1: un composant de donnée ne donne pas lieu à une opération de traitement et ne peut donc pas contenir de transition.
Les déclarations de composant de donnée AADL ne sont pas traduites dans le réseau, puisque celui-ci ne rend compte que des entités instanciées. Par ailleurs, contrairement à la traduction en langage de programmation, nous ne nous intéressons pas à la sémantique des données : toutes les déclarations de données sont donc considérées équivalentes vis-à-vis des flux d’exécution. La vérification de la cohérence des types doit être réalisée par ailleurs.
VII-4.1.2 Traduction des composants « actifs »
Tous les composants autres que les données recueillent des données en entrée, les traitent et produisent des données en sortie. Les figuresVII.2(b) etVII.2(c) illustrent les modélisations correspondant aux différents composants AADL considérés.
Règle VII.5 (Traduction des types de composants)
Les composants « actifs » de haut niveau (systèmes, processus, threads) d’une architec- ture sont traduits par une transition (représentant le composant lui-même) entourée de places modélisant ses éléments d’interface.
Cette approche assure la cohérence du formalisme vis-à-vis de la syntaxe AADL : en effet, les ports des composants – que nous modélisons en réseaux de Petri par des places – sont typiquement associés à une déclaration de composant de donnée. Un composant de donnée est donc toujours représenté par une place, qu’il s’agisse d’une instance – c’est-à-dire un sous-composant – ou d’un élément d’interface.
Notons que cette modélisation de haut niveau implique qu’un composant a besoin de recevoir des données sur tous ces ports pour s’exécuter. Pour les threads, cette hypothèse correspond aux spécifications que nous avons définies au chapitre IV; ce n’est en revanche pas le cas pour les autres composants, tels que les systèmes. En l’absence d’information sur la structure interne du composant considéré, cette hypothèse, bien que forte, est cependant assez naturelle et permet une modélisation systématique.
Afin de systématiser la traduction, nous créons une place par élément d’interface. De cette façon, il est notamment possible d’appliquer éventuellement des traitement différents à chaque élément d’interface lors de la génération du réseau de Petri – par exemple des fusions de places.
Règle VII.6 (Traduction des éléments d’interface)
Chaque élément d’interface est traduit par une place reliée à la transition représentant le composant considéré.
Un port d’entrée d’événement/donnée ou un accès à un sous-composant de donnée est traduit par une place connectée à la transition du composant.
Un port d’entrée de donnée est traduit par une place dont le marquage initial est u. La transition du composant consomme le jeton de cette place et le restitue. La transition du composant comporte une garde l’empêchant de se déclencher avec un jeton de couleur u.
Tous les ports de sortie sont traduits par une place de sortie reliée à la transition du composant.
Les ports d’entrée/sortie sont assimilés à un couple de ports, l’un en entrée, l’autre en sortie.
Toutes les places représentant un port sont du domaine Comm. Les accès aux bus ou aux sous-programmes ne sont pas traduits.
Un port de donnée ne comporte pas de file d’attente ; une donnée stockée dans un tel port n’est donc pas consommée : elle est seulement lue. Le marquage initial des places correspondantes correspond à la valeur indéfinie u afin d’empêcher le composant de se déclencher avec ce qui correspond en fait à une absence de valeur.
Nous ne traduisons pas les accès aux bus car ces composants ne sont pas pris en considéra- tion dans notre traduction. La prise en charge des accès à sous-programmes sera étudiée dans la sectionVII-5.3.
Les threads AADL sont les éléments actifs de l’architecture. Pour rendre compte de cet aspect, leur traduction en réseau de Petri fait apparaître un jeton représentant le contrôle d’exécution du thread. Ce jeton de contrôle constitue le marquage initial d’une place associée au thread. La mo- délisation du circuit du jeton de contrôle dépend de la politique de déclenchement du thread. Les threadspériodiques, apériodiques et sporadiques s’exécutent en boucle. Ils consomment donc leur jeton de contrôle et le restituent dans la place initiale (figureVII.2(b)). Ces trois types de threads se modélisent de la même façon alors qu’ils correspondent à des politiques de déclenchement dif- férentes, comme nous l’avons étudié au chapitreVI. Ceci est dû au fait que notre modélisation en réseau de Petri ne tient pas compte des propriétés temporelles de l’architecture : nous ignorons donc les situations dans lesquelles un thread devrait se déclencher alors que les données entrantes ne sont pas disponibles.
Les threads s’exécutant en tâche de fond ne bouclent pas. Leur traduction en réseau de Petri ne doit donc pas restituer le jeton de contrôle, qui est consommé définitivement (figureVII.2(c)). Pour des raisons de régularité dans la représentation en réseau de Petri, tous les threads ont une structure semblable ; la transition de retour des threads périodiques trouvera par ailleurs sa justification dans la sectionVII-5.3.1.
La traduction d’une description AADL en réseau de Petri a pour objet l’analyse des flux de données et d’exécution. Par conséquent, seuls les composants ayant un rôle dans ces flux doivent apparaître.
Règle VII.7 (Traduction des processus et des systèmes)
Un processus ou un système contenant des sous-composants n’est pas traduit en réseau de Petri. Seuls ses sous-composants sont transcrits dans le réseau de Petri. À l’inverse, un processus ou un système dont l’implantation n’est pas spécifiée apparaît dans le réseau de Petri, assimilé à un thread.
Le réseau de Petri correspondant à une architecture AADL de haut niveau est la mise à plat de toutes les instances des threads, qui représentent les entités réellement impliquée dans les flux d’exécution et de données.
Les processus et les systèmes sans sous-composants sont traduits dans le réseau de Petri. Dans la mesure où aucune information n’est disponible quant à leur structure interne, nous pouvons considérer qu’ils contiennent un thread ; nous les assimilons donc à ce thread supposé afin de les intégrer dans la modélisation du flux d’exécution. De tels systèmes ou processus sont donc traduit par un sous-réseau de Petri tel que représenté sur la figureVII.2(b).