Nous pr´esentons d’abord en section 5.2.1, les grandes lignes concernant l’am´elioration de la m´ethodologie qui vient d’ˆetre expos´ee. Il s’agit d’une part, de d´efinir des mod`eles de composants permettant de repr´esenter des m´ecanismes asynchrones et d’autre part, d’´etendre les techniques de validation disponibles dans Polychrony. Cette th`ese traite en grande partie du premier point. La section 5.2.2 introduit ainsi les approches utilis´ees dans les chapitres suivants pour d´ecrire des composants enSignal.
5.2.1 D´emarche propos´ee
Une observation g´en´erale est que le niveau de d´etail requis pour d´ecrire l’architecture d’une application d´epend souvent du degr´e de raffinement choisi pour le mapping sur l’architecture. En d’autres termes, dans les cas les plus simples, la quantit´e d’informations dont on a besoin est raisonnablement petite, et simple `a estimer :
– L’ensemble des processeurs ou des tˆaches, et le mapping des op´erations ou des sous-processus d´efinis dans la sp´ecification de l’application sur ces processeurs ou tˆaches. Ces informations permettent de partitionner le graphe repr´esentant l’application en sous-graphes, selon le mapping;
– La topologie du r´eseau de processeurs, l’ensemble des connexions entre processeurs et lemapping des communications entre processus sur ces liens de communication. Cela est utile notamment lorsque des signaux ´echang´es par des processus situ´es sur des processeurs diff´erents, ou dans des tˆaches diff´erentes, doivent ˆetre achemin´es via le mˆeme m´edium de communication ;
– Une d´efinition d’un ensemble de primitives de niveau syst`eme, utilis´ees par exemple pour les communications (lectures et ´ecritures sur un m´edium). D’une certaine fa¸con, cela revient `a d´efinir les profils de la biblioth`eque de fonctions auxquelles le code g´en´er´e pour l’application devra ˆetre li´e.
Des raffinements suppl´ementaires de la description peuvent ˆetre n´ecessaires pour une meilleure adaptation de l’architecture : par exemple, en ce qui concerne le type et la nature des liens de communication (ces derni`eres peuvent ˆetre mises en œuvre `a l’aide de variables partag´ees, de communications synchrones ou asynchrones...). D’autre part, si l’architecture cible est ca-ract´eris´ee par un syst`eme d’exploitation, le mod`ele requis consistera typiquement en un profil des primitives correspondantes. Par exemple, selon le niveau d’utilisation du syst`eme d’exploita-tion, nous aurons besoin de mod`eles de portes de synchronisad’exploita-tion, de communications (incluant ´eventuellement des routages entre processeurs) ou de fonctions de gestion de tˆaches (dans le cas de tˆaches non interruptibles : d´emarrer et arrˆeter une tˆache ; pour des tˆaches interruptibles : suspendre et reprendre l’ex´ecution d’une tˆache, ou affecter une priorit´e `a une tˆache).
D´efinition d’un ensemble de composants. Dans le but de raffiner les descriptions obtenues `
a l’issue des ´etapes de la m´ethodologie, nous proposons un ensemble de composants, utilisables pour mod´eliser divers aspects au sein d’une application : m´ecanismes de communication asyn-chrone, supports d’ex´ecution (exemples : tˆaches, processus), primitives de niveau syst`eme pour la gestion de tˆaches, pour la communication et la synchronisation entre tˆaches. Ces compo-sants sont regroup´es au sein d’une biblioth`eque accessible dans Polychrony. Le sch´ema de la Fig. 5.5 illustre la fa¸con dont sont utilis´es ces mod`eles dans le cadre d’une am´elioration de la m´ethodologie : les descriptions obtenues apr`es l’´etape 2 deviennent instanciables dans un mod`ele de mise en œuvre constitu´e de composants provenant de notre biblioth`eque. Chaque
pour chaque processeur, incluant
d’une application
mod`ele SIGNAL de l’architecture-cible
compos´ee de deux processeurs les processeurs
rajout´ees automatiquement entre apr`es partitionement et compilation,
le mˆeme mod`ele de l’application particuli`ere
biblioth`eque SIGNAL de composants
Code enfoui g´en´er´e (C, Java...)
de communication
mod`ele SIGNAL
- V´erification - Simulation... des communications synchrones sont
des appels `a des services
refl´etant une implantation
- ´Eval. de Perf.
Figure 5.5 – Am´elioration de la m´ethodologie de conception d’applications distribu´ees.
mod`ele de processeur peut d´esormais ˆetre explicit´e en faisant apparaˆıtre clairement les tˆaches s’ex´ecutant sur celui-ci. L’ex´ecutif temps r´eel qui prend en charge la gestion de ces tˆaches est ´egalement mod´elisable `a l’aide des primitives de niveau syst`eme d´ecrites dans la biblioth`eque. Enfin, des mod`eles de m´ecanismes asynchrones sont propos´es pour d´ecrire les communications.
Extension des techniques de validation dans Polychrony. La seconde am´elioration apport´ee `a la m´ethodologie concerne les techniques de validation qui y sont utilis´ees. Nous avons d´ej`a soulign´e que l’avantage d’un formalisme tel queSignalest incontestablement sa capacit´e `a faciliter l’analyse des mod`eles d´ecrits. Cela est possible grˆace `a sa s´emantique formelle qui permet de raisonner sans ambigu¨ıt´e sur ces mod`eles. Parmi les techniques classiques de v´erification applicables `a un programme, nous mentionnons l’interpr´etation abstraite ou lemodel checking. Des outils associ´es sont disponibles dans Polychrony. Ici, la nouveaut´e consiste surtout en la mise en œuvre de la technique d’´evaluation de comportements temps r´eel pr´esent´ee au chapitre 4. Ce qui permet de disposer d’un moyen d’´etudier quantitativement le comportement temporel des applications sur leurs architectures mat´erielles de d´eploiement. La r´epartition du graphe logiciel d’une application sur des processeurs ´etant effectu´ee suivant les d´ecisions de l’utilisateur, ce dernier doit valider ses choix afin de s’assurer que les performances des processeurs satisfont bien les crit`eres requis pour que l’application r´ealise correctement la mission qui lui est affect´ee. L’utilisation d’une interpr´etation temporelle de l’application comme observateur est un moyen permettant de v´erifier les propri´et´es temporelles de celle-ci en vue de sa validation.
∗ ∗ ∗
Une contribution importante de cette th`ese est la d´efinition des mod`eles de composants. La pr´esentation de ceux-ci est abord´ee dans les chapitres 6 et 8. Nous introduisons ici les approches suivies pour d´efinir ces composants (section 5.2.2).
5.2.2 D´efinition de composants de description d’architectures
Pour d´efinir nos composants, nous utilisons deux d´emarches qui sont classiques en concep-tion. L’une est qualifi´ee dedescendante tandis que l’autre est dite ascendante.
5.2.2.1 Approche descendante
La conception d’un syst`eme suivant une approche ditedescendanteconsiste `a d´eriver, `a partir d’une description tr`es g´en´erale, une mise en œuvre particuli`ere de celui-ci. G´en´eralement, cette d´emarche doit respecter un certain nombre d’´etapes : d’abord l’identification des diff´erents sous-syst`emes et les m´ecanismes de communication n´ecessaires, ensuite la d´efinition des op´erations associ´ees `a ces sous-syst`emes, enfin la mise en œuvre explicite des algorithmes.
En Signal, une mod´elisation d’un composant consiste `a consid´erer sadescription abstraite, une description initiale de celui-ci, qui par la suite estraffin´ee pour d´eriver une description plus pr´ecise. On it`ere le processus jusqu’`a l’obtention du mod`ele final souhait´e. En se basant sur ce principe, les composants sont d’abord d´ecrits de mani`ere abstraite `a travers certaines de leurs propri´et´es (par exemple, leurs propri´et´es d’interface). Le choix de celles-ci d´epend g´en´eralement de l’utilisation ult´erieure dont ces composants feront l’objet. Dans le chapitre 8, nous nous basons sur une approche descendante pour d´ecrire des services d’un ex´ecutif temps r´eel.
5.2.2.2 Approche ascendante
Dans une approche de conception qualifi´ee d’ascendante, on identifie d’abord les composants de niveaux inf´erieurs. Ces derniers sont alors d´efinis, puis utilis´es pour r´ealiser les composants du niveau au-dessus et ainsi de suite, jusqu’`a la description du composant principal. C’est donc une approche incr´ementale. La modularit´e du langageSignalfacilite une telle d´emarche. Supposons un composant cd´efini par le mod`ele Signalsuivant :
P =P1 |...|Pn
o`u chaquePi (i∈[1..n]) d´enote le programme associ´e `a un sous-composant dec. On commence par d´efinir l’un desPi, par exempleP1, on fait de mˆeme pourP2, et on compose les deux mod`eles pour obtenir P1,2. Ensuite, la composition de P1,2 avec P3 d´efinit P1,2,3, et ainsi de suite. On r´eit`ere le processus avec tous les sous-composants restants jusqu’`a l’obtention de P1,...,n, qui mod´elise le composant c. Nous pr´esentons deux mod`eles d’abstraction d´efinis en Signal qui peuvent s’inscrire dans le cadre d’une d´emarche de conception ascendante : abstractions boˆıte noire etboˆıte grise. Ces mod`eles offrent des vues abstraites d’une description que nous pouvons qualifier deboˆıte blanche: o`u les comportements internes du composant d´ecrit sont enti`erement explicit´es.
Spécifications SIGNAL des propriétés de l'interface du
composant Vue «fermée» du composant
Entrées Sorties
Figure 5.6 – Mod`eleboˆıte noire d’un composant.
par la description de chacun des composants tient compte au minimum de la sp´ecification des propri´et´es d’interface. Elles indiquent notamment comment un composant peut ˆetre connect´e aux autres composants. Dans certains cas, cela est suffisant pour caract´eriser le composant, et permettre d’´etudier des propri´et´es comportementales du syst`eme global form´e par l’ensemble composants.
Une descriptionSignald’un composant peut ˆetre obtenue en “encapsulant” celui-ci dans un mod`ele de processus, qui sera utilis´e comme une “boˆıte noire” par la suite. Son interface d´ecrit les entr´ees et les sorties. Elle sp´ecifie notamment les d´ependances et les relations d’horloges qui existent entre les entr´ees/sorties. Un tel mod`ele, comme le montre la Fig. 5.6, est en partie consid´er´e comme ´etantexternelors de l’analyse statique, car sa mise en œuvre n’est pas connue
a priori. Seules les propri´et´es d’interface sont trait´ees.
Mod`ele boˆıte grise. La principale limitation du mod`ele boˆıte noire est qu’il ne permet pas d’analyses fines du composant. Par cons´equent, si on veut ˆetre capable de raisonner davantage sur les propri´et´es de celui-ci, il faut une abstraction moins “grossi`ere” de la description. Pour ce faire, on proc`ede `a des analyses qui permettent de s´eparer le composant en sous-composants fonc-tionnellement coh´erents. Ces analyses reposent essentiellement sur les relations de d´ependance et les contraintes de synchronisation sp´ecifi´ees dans le programmeSignalrepr´esentant le com-posant. Chaque sous-composant est repr´esent´e par un mod`ele boˆıte noire. Des interconnexions sont sp´ecifi´ees entre les composants r´esultants. Enfin, les horloges d’activation des sous-composants sont fournies. C’est ce que nous avons sch´ematis´e sur laFig. 5.7, o`u le composant principal est dor´enavant ´eclat´e en quatre sous-composants.
Spécifications SIGNAL des propriétés de l'interface du composant, des sous-
Figure 5.7 – Mod`eleboˆıte grise d’un composant.
Le mod`ele boˆıte grise offre ainsi une vue op´erationnelle plus pr´ecise qu’un mod`ele boˆıte noire d’un composant (donc, plus de possibilit´es pour ´etudier des propri´et´es comportementales de celui-ci). Plus la granularit´e des sous-composants est faible, plus le mod`ele est pr´ecis. Cela veut dire que l’on peut `a nouveau appliquer le principe `a chaque sous-composant et ainsi de suite, jusqu’`a ce que le niveau de d´etail souhait´e soit atteint (par exemple, lorsqu’on n’obtient que des boˆıtes blanches).
Pour des syst`emes d´efinis `a partir de composants provenant d’origines diverses, l’abstraction constitue un moyen appropri´e pour ´etablir leur int´egration. Le formalisme sous-jacent utilis´e est parfois qualifi´e de “glue”. La description de l’architecture d’un syst`eme `a l’aide du langage
MetaH[210] repose sur ce principe (cf. chapitre 1). Les modules externes sont encapsul´es dans des boˆıtes noires sp´ecifi´ees en MetaH. Les propri´et´es du syst`eme r´esultant sont ´etudi´ees `a partir des propri´et´es extraites des modules encapsul´es (exemples : dur´ee d’ex´ecution du code associ´e `a un module, ordonnancements au sein du module). L’approche ascendante est illustr´ee dans le chapitre 6, o`u nous mod´elisons une file de messages utilisable dans un protocole de communication asynchrone.