Possibilités d’extension des composants

L’extension de composant AADL ne correspond pas exactement à la notion d’héritage des langages objet : un composant et son extension constituent des composants distincts ; il n’est pas possible d’utiliser l’un pour l’autre au sein d’une description architecturale. En revanche, les im- plantations d’un type de composant peuvent être substituées les unes aux autres dans la mesure où elles partagent la même interface aux autres composants.

III-3 Structure interne des composants

La structure interne des composants peut être précisée dans la déclaration des implantations des composants.

III-3.1 Sous-composants

Un sous-composant est une instance de la déclaration d’un composant. De cette façon, une ar- chitecture modélisée en AADL est une arborescence de d’instances de composants. La déclaration d’un sous-composant doit être associée à une catégorie, un type ou une implantation de compo- sant ; il est ainsi possible d’apporter plus ou moins de précision dans la description architecturale. En ne spécifiant que la catégorie du sous-composant, la description architecturale demeure vague ; elle ne peut pas être exploitée pour générer un système exécutable, mais peut être employée à des fins de documentation.

Une description architecturale complète doit préciser l’implantation de composant utilisée pour chaque sous-composant.

AADL définit les règles de composition des composants ; seules les combinaisons ayant une sémantique cohérente sont autorisées. Le tableauIII.1fait la synthèse des compositions possibles.

composant sous-composants

donnée données

sous-programme —

thread —

groupe de threads threads

processus threads, groupes de threads processeur mémoires

mémoire mémoires

bus —

dispositif —

système données, processus, processeurs, mémoires, dispositifs, bus, systèmes

TAB. III.1 – Compositions légales des composants AADL

Nous pouvons remarquer que les sous-programmes ne sont jamais instanciés. En effet, la sé- mantique d’AADL traduit le fait qu’en terme de langage de programmation, un sous-programme n’est en fait qu’une séquence de code stockée dans l’espace mémoire d’un programme : ce n’est pas une entité en soi. Nous reviendrons sur ce point en sectionIII-9.

De la même façon, un processus ne peut pas être un sous-composant d’un processeur : un programme est en effet exécuté par un processeur, mais n’est pas intégré dedans.

Dans la mesure où un dispositif modélise une boîte noire, il ne peut pas avoir de sous-composant. Un composant mémoire peut être contenu dans un processeur ou une autre mémoire pour modéliser un cache mémoire ou une partition de disque dur.

Les systèmes peuvent contenir toutes les catégories de composants sauf les sous-programmes (qui ne peuvent pas être instanciés) et les threads et groupes de threads, qui doivent appartenir à un processus – un fil d’exécution ne peut en effet pas exister en dehors de l’espace mémoire qui délimite son exécution.

III-3.2 Appels de sous-programmes

Les appels de sous-programmes modélisent les appels de procédures dans les langages im- pératifs. Ils sont regroupés en séquences d’appels dans les sous-programmes et les threads. Bien que la syntaxe utilisée soit semblable à la déclaration d’un sous-composant, un appel de sous- programme ne représente pas une instance de sous-programme. L’approche d’AADL correspond donc aux principes des langages de programmation : chaque sous-programme appelé est implici- tement instancié une fois dans la mémoire du processus, et peut-être appelé plusieurs fois.

1 process processus_a 2 end processus_a; 3 4 thread thread_a 5 end thread_a; 6

7 process implementation processus_a.impl

9 thread1 : thread thread_a.impl;

10 end processus_a.impl;

11

12 thread implementation thread_a.impl

13 calls

14 sequence : {appel1 : subprogram sp_a;

15 appel2 : subprogram sp_a;};

16 end thread_a.impl;

17

18 subprogram sp_a

19 end sp_a;

Listing III.2 – Structure interne des composants AADL

III-4 Les éléments d’interface

Les éléments d’interface (features) d’un composant sont déclarée dans son type. De cette fa- çon, toutes les implantations d’un type de composant offrent la même interface aux autres com- posants. Il existe plusieurs sortes de features : les ports de communication, les sous-programmes d’interface et les accès à sous-composants. Les déclarations de features peuvent n’être associées à aucune déclaration de composant, permettant ainsi une modélisation très abstraite. Cependant, il est nécessaire de préciser les composants associés afin de décrire une architecture exploitable pour générer un système exécutable.

III-4.1 Les ports

Les ports correspondent à la principale façon de décrire les transmissions d’information entre les composants. Ils sont déclarés en entrée, en sortie ou en entrée/sortie.

III-4.1.1 Ports simples

On distingue trois types de ports : – les ports d’événement ;

– les ports de donnée ;

– les ports d’événement/donnée.

Les ports d’événement (event ports) correspondent à la transmission d’un signal. Ils peuvent être assimilés aux signaux des systèmes d’exploitation. Ils peuvent également déclencher l’exécu- tion des threads.

Les ports de donnée (data ports) correspondent à la transmission de données. Contrairement aux ports d’événements, ils ne déclenchent rien à la réception ; ils peuvent donc modéliser un registre mémoire mis à jour de façon asynchrone.

Les ports d’événement/donnée (event data ports) sont la synthèse des deux premiers types de ports : ils permettent de transporter des données tout en générant un événement à la réception ; ils permettent donc de modéliser un message.

Les ports peuvent constituer les interfaces des composants concernés par les flux d’exécution : threads, groupes de threads, processus, dispositifs, systèmes et processeurs. Dans le cas des sous- programmes, on parle de paramètres. Les paramètres ont une sémantique équivalente aux ports de données ou d’événement/données.

III-4.1.2 Groupes de ports

La manipulation des ports de communication peut conduire à la déclaration d’ensembles constants. Par exemple, la description de composants communicant par l’intermédiaire d’un port série de type RS232 entraînera la déclaration répétée des ports correspondant aux signaux de cette interface. Pour faciliter la manipulation de ports souvent associés, le standard AADL définit la notion de groupe de ports (port group).

La déclaration d’un groupe de port est similaire à celle d’un type de composant. Il est possible de définir un groupe de port comme étant l’inverse d’un autre. L’inverse d’un groupe de ports est constitué des mêmes ports, dont les directions sont inversées.

III-4.2 Les sous-programmes d’interface

Les sous-programmes d’interface permettent de décrire des appels de méthode. Un sous- programme d’interface peut-être fourni par un composant de donnée ; dans ce cas il définit une méthode associée à une classe, reprenant ainsi les concepts définis par la programmation objet. Un sous-programme d’interface peut également être fourni par un thread ; il modélise un sous- programme invocable à distance (RPC, Remote Procedure Call).

Les sous-programmes d’interface sont un moyen alternatif de décrire les échanges de données entre les composants AADL. Les constructions syntaxiques qui leur sont associées dans la version 1.0 ne sont pas très développées. Notamment, il n’existe pas de construction syntaxique permettant d’exprimer le fait qu’un sous-programme appelé doit correspondre au sous-programme d’interface fourni par un thread. La modélisation complète d’une architecture basée sur un mécanisme de RPC s’en trouve compliquée. La version 1.2 du standard fournit les constructions syntaxiques nécessaires, comme nous le verrons en sectionIII-9.

III-4.3 Les accès à sous-composant

Les accès à sous-composants permettent d’exprimer le fait qu’un sous-composant défini au sein d’un composant peut être partagé avec d’autres composants. Il existe deux types d’accès à sous-composants : pour les bus et les données. Dans les deux cas, ils sont déclarés comme étant des accès fournis (provides) ou requis (requires).

Dans le cas d’un composant de données, un accès permet de modéliser une variable partagée : le composant de donnée est instancié une fois et manipulé par plusieurs composants. L’accès à un bus permet de représenter le partage d’un bus entre différents composants matériels, modélisant ainsi l’interconnexion entre les processeurs, les dispositifs et les mémoires.

III-4.4 Synthèse sur les éléments d’interface

Des exemples de syntaxe pour la déclaration des éléments d’interface sont présentés au lis- tingIII.3. 1 system systeme_a 2 features 3 a : in data port; 4 end systeme_a; 5

6 system systeme_b extends systeme_a

7 features

9 b : requires data access donnee;

10 c : port group groupe_de_ports;

11 end systeme_b;

12

13 data donnee

14 end donnee;

15

16 port group groupe_de_ports

17 features

18 p1 : in data port donnee;

19 p2 : in out event data port donnee;

20 end groupe_de_ports;

21

22 process process_a

23 features

24 e : in event port;

25 s : out event data port;

26 end process_a; 27 28 subprogram sous_programme_a 29 end sous_programme_a; 30 31 thread thread_a 32 features

33 sp : server subprogram sous_programme_a;

34 end thread_a;

Listing III.3 – Exemples d’éléments d’interface

De la même façon que pour les sous-composants, le standard AADL définit les éléments d’in- terface possibles pour chaque catégorie de composant. Le tableau III.2fait les synthèses de ces possibilités. systeme_b thread_a a b c sp process_a e s

FIG. III.5 – Syntaxe graphique des éléments d’interface, correspondant au listingIII.3