CONSTRUCTION DU FEATURE MODEL

— La partie comportement temporel, comportant les param`etres temporels du syst`eme, comme ceux d´ecrits dans la section 2.3.3. Cette partie permet de d´eterminer le comportement tem-porel du syst`eme.

La figure 6.7 propose un feature model pour les syst`emes temps r´eel. Sur cette figure appa-raissent les trois grandes parties d’un syst`eme.

Dans la partie mat´erielle, un r´eseau peut ˆetre instanci´e, sous la forme d’un bus ou bien sous la forme d’un r´eseau commut´e (not´e Switched sur la figure). Les processeurs du syst`eme peuvent ˆetre tous des monoprocesseurs ou des multiprocesseurs homog`enes, h´et´erog`enes ou uniformes.

Dans la partie logicielle, il est possible de choisir le nombre de processus dans le syst`eme. Notons au passage que suivant la plateforme cible, il n’est pas toujours possible de cr´eer plusieurs processus sur un unique processeur. Par exemple, le syst`eme d’exploitation temps r´eel VxWorks offre la possibilit´e de cr´eer plusieurs processus sur un mˆeme processeur. Cependant, POSIX, dans son profil minimaliste PSE 51 [IEE03] souvent utilis´e pour le temps r´eel, ne propose qu’un processus, de mˆeme qu’AUTOSAR/Osek [C+13] tr`es utilis´e dans le domaine automobile.

Dans le cas de plusieurs processus, les processus peuvent ˆetre hi´erarchis´es ou non. Les tˆaches peuvent soit interagir entre elles, soit ˆetre ind´ependantes entre elles. Les ressources peuvent ˆetre prot´eg´ees par un s´emaphore d’exclusion mutuelle, ou bien ne pas exister. Les tˆaches peuvent transmettre des messages de fa¸con locale ou par le biais d’un r´eseau. Dans ce dernier cas, le r´eseau doit ˆetre s´electionn´e, et r´eciproquement un message r´eseau doit ˆetre transmis si un r´eseau est pr´esent.

Dans la partie ordonnancement, le comportement temporel des tˆaches peut ˆetre d´ecrit en utilisant une date de r´eveil, un d´elai critique, une p´eriode. Les tˆaches peuvent ˆetre pr´eemptibles ou non.

Dans ce mod`ele descriptif de besoins, on note ´egalement la pr´esence de contraintes non exprimables directement dans l’arbre. Ces contraintes lient des nœud se trouvant sur des branches diff´erentes. Ici, lorsqu’un r´eseau est demand´e dans la partie mat´erielle (nœud Network ), les messages r´eseau doivent ´egalement apparaˆıtre dans la partie logicielle (nœud NetworkMessage) et r´eciproquement.

F igure 6. 7 – M o d `ele de b esoi n s (ou F eatu re M ode l) p our les sy st `em es te mp s r´ee l

6.5. CONSTRUCTION DUFEATURE MODEL

6.5.3 Transpositions des besoins dans le langage de mod´elisation MoSaRT

Une fois que les besoins sont d´efinis, il est n´ecessaire de faire une correspondance avec le langage de mod´elisation. On a propos´e un mod`ele de besoins permettant d’identifier les besoins du syst`eme temps r´eel con¸cu. Ces besoins doivent ˆetre utilis´es pour cr´eer un point de vue du langage de mod´elisation. On propose une plateforme permettant d’´elaguer les langages adapt´es au temps r´eel `a l’aide du mod`ele de besoin. Nous allons ´elaguer le langage MoSaRT.

A chaque nœud, on fait correspondre un ensemble de classes `a garder. Le feature Model s’inspire ainsi fortement des contextes du r´ef´erentiel d’analyses. Pour repr´esenter le besoin ex-prim´e dans le m´eta-mod`ele, on propose de rassembler toutes les correspondances entre le nœud et le m´eta-mod`ele dans un r´ef´erentiel de mapping. Le r´ef´erentiel consiste `a stocker toutes les correspondances dans un mod`ele d´ependant du m´eta-mod`ele cible. Ainsi, on propose dans la figure 6.8, un m´eta-mod`ele correspondant `a ce r´ef´erentiel. Sur cette figure, le MappingDatabase est la classe racine du mod`ele. Cette figure exprime les relations entre le besoin (not´e Feature sur la figure) et les classes, attributs et r´ef´erences Ecore (not´ees respectivement Eclass, EAttri-bute, et EReference sur la figure. Les ´el´ements du m´eta-mod`ele Ecore li´es au besoin doivent ˆetre dans le point de vue extrait. Chaque Feature d´ecrit le besoin exprim´e dans la classe Relation.

Figure 6.8 – M´eta-mod`ele du mapping

Une instance de correspondance est montr´ee sur la figure 6.9. Sur cette figure, on ne pr´esente que la partie correspondant `a l’extraction de tˆaches p´eriodiques, pr´eemptives sur le m´eta-mod`ele MoSaRT.

En s´electionnant les nœuds Periodic et Preemptive, les nœuds p`eres (Periodicity, Preempti-vity, TemporalBehavior, TaskSet et TemporalPart) sont automatiquement s´electionn´ees. `A cha-cun de ces nœuds, on doit affecter des classes qui doivent ˆetre retenues dans le sous-m´eta-mod`ele (le point de vue). Le nœud TaskSet indique la pr´esence de tˆaches : la classe SoSchedulableTask (cf. figure 3.13) est donc s´electionn´ee. Le nœud TemporalBehavior indique que des les tˆaches ont un comportement temporel : le conteneur des ´el´ements comportementaux et l’activation des tˆaches doivent ˆetre retenus (respectivement les classes GlobalBehavior et SbTimeTrigger de la figure 3.14).

Une activation peut ˆetre soit p´eriodique, sporadique ou ap´eriodique. Le nœud Periodic ca-ract´erise uniquement l’activation p´eriodique d’une tˆache, lorsqu’elle est s´electionn´ee, Donc, si les tˆaches sont uniquement p´eriodiques, seul le nœud Periodic doit ˆetre s´electionn´e. En revanche, si les tˆaches peuvent ˆetre activ´ee de diff´erentes fa¸cons, les autres nœuds doivent ˆetre s´electionn´es.

Figure 6.9 – Extrait d’une instance de mapping

6.6 Int´egration - Exemple

Dans cette section, nous int´egrons cette plateforme `a l’aide d’outils existants pour permettre la g´en´eration et l’utilisation de points de vue sur un langage. Ce processus est ensuite appliqu´e sur un cas simple de point de vue.

6.6.1 Int´egration dans un processus de g´en´eration d’un point de vue

Le processus appliqu´e pour construire un point de vue est pr´esent´e sur la figure 6.10. `A partir du mod`ele de besoins (c’est-`a-dire `a partir de l’ensemble des ´el´ements du dictionnaire que nous avons propos´e sour forme de Features Model ), l’expert cr´ee les correspondances `a l’aide du langage cr´e´e dans la figure 6.8. Cela donne un mapping similaire `a la figure 6.9. Ce mappint est fait une seule fois pour chaque langage. Ensuite, le concepteur logiciel peut d´efinir ses besoins `

a l’aide du Feature Model. Une fois que les besoins sont exprim´es, on utilise l’outil d’´elagage de m´eta-mod`eles. Cet outil donnera un m´eta-mod`ele ´elagu´e pour cr´eer un sous-m´eta-mod`ele `a partir du mapping cr´e´e par l’expert du m´eta-mod`ele et aussi des besoins exprim´es par le concepteur logiciel.

L’outil du processus d’´elagage que nous avons cr´e´e est d´etaill´e dans la figure 6.11. `A partir des besoins de l’utilisateur et du mapping, il est possible de d´eterminer les classes `a extraire du m´eta-mod`ele, et inversement `a retirer du m´eta-mod`ele, `a l’aide d’un parseur Java, dans l’optique d’utiliser ATL car il est dot´e d’une option de raffinement ne poss´edant que des fonctions de suppression de classes (c’est-`a-dire les classes qui n’ont pas ´et´e s´electionn´ees).