Expérimentation de RAMSES

Expérimentation de RAMSES

Nous avons défini le framework RAMSES qui implémente le processus de génération de code que nous avons proposé aux chapitres précédents. Ce framework s’appuie sur la formalisation d’un workflow qui orchestre le processus de génération en définissant différentes stratégies de génération aux différentes étapes de raffinement. Cette démarche a été intégrée au sein de l’envi- ronnement OSATE.Dans ce chapitre, nous expérimentons ce framework sur le raffinement des communications entre tâches. Premièrement, la section 7.1 illustre les patrons de transformation dans ce contexte particulier. Nous démontrons ainsi l’applicabilité de ces patrons sur des cas concrets d’utilisation. Ensuite, la section 7.2 donne un exemple de processus mis en œuvre par RAMSES. Nous formal- isons ce processus à l’aide du modèle de workflow que nous avons défini aux chapitres précédents et nous démontrons l’intérêt d’un tel processus capable d’adapter la génération de code selon les propriétés du système modélisé.Le patron Stratégie s’applique pour modifier une partie du comportement d’une règle de trans- formation. Son principe est de déléguer certains traitements ou certaines expressions à une fonc- tion annexe que l’on remplace selon le besoin. Nous l’avons exploité pour faire varier le nombre d’appels au composant Send_Output selon l’implémentation au sein d’une règle principale inté- grant l’ensemble des composants de communication. Cette règle est illustrée par le listing 7.1 et concerne les implémentations PDC_Indices et PDC_Indices_Array. Pour ces deux versions, le composant Send_Output prend en paramètre le port de réception du destinataire. Pour cette raison, la règle parcourt 1) l’ensemble des ports d’émission de l’émetteur (ligne 16) puis 2) l’ensemble des ports de réception connectés à ce dernier (ligne 18). Enfin, 3) Send_Output est appelé et prend en paramètre le port de réception courant (lignes 19 et 20).

Si nous souhaitons maintenant mettre en œuvre PDC_InsertionSort, il faut noter que le com- posant Send_Output ne prend aucune file de message en paramètre (voir section 5.3.4) : par con- séquent il ne doit être appelé qu’une seule fois par période. La règle du listing 7.1 n’est donc pas réutilisable telle quelle. On peut cependant vouloir la réutiliser étant donné que les lignes 1 à 15 sont identiques (le nombre d’appels aux autres composants de communication étant le même entre les trois implémentations). Pour l’implémentation PDC_InsertionSort, les lignes 16 à 22 doivent être modifiées. Nous utilisons le patron Stratégie pour remplacer cette portion de code tout en conservant la logique globale de la règle existante. Cette portion de code est déléguée à une règle annexe (listing 7.2) et remplacée par un appel à cette dernière (listing 7.3).Il suffit alors de superimposer cette règle annexe pour modifier ces quelques lignes de code et ainsi obtenir un unique appel au composant Send_Output. Ainsi, dans le cas de PDC_InsertionSort, une nouvelle définition de la règle Insert_Send_Output_Service_In_CallSequence est superim- posée (listing 7.4) afin de modifier le comportement de la règle Insert_Communication_Services _In_CallSequence. La ligne 4 du listing 7.4 insère ainsi le composant Send_Output une seule fois par tâche.

Adaptateur

Le patron Adaptateur vise à réutiliser une règle existante pour des éléments dont la logique de raffinement est similaire aux éléments d’entrée de la règle mais dont l’interface les rend in- compatibles avec cette dernière. Le principe est de rendre virtuellement compatible l’interface des nouveaux éléments en définissant des fonctions annexes rattachées au type de ces éléments. Nous avons expérimenté ce patron sur le raffinement des ressources partagées entre tâches. Le modèle AADL du listing 7.5 spécifie une donnée sharedData (ligne 3) partagée en exclusion mutuelle entre les tâches reader et writer (ligne 5). La propriété Concurrency_Control_Protocol précise le protocole d’exclusion utilisé à la ligne 4.Ce modèle utilise une notation implicite de l’exclusion mutuelle en se limitant à spécifier une propriété d’exclusion. Un raffinement possible d’un tel modèle serait d’expliciter les mécanismes utilisés pour délimiter les sections critiques. Ces mécanismes sont modélisés par les composants Get_Resource et Release_Resource que nous avions introduits aux chapitres précédents. La règle Protected_Shared_Data du listing 7.6 illustre ce raffinement : pour chaque donnée partagée, on la conserve (ligne 10 : copie de la donnée, ligne 11 : copie de son type) et on ajoute les composants Get_Resource et Release_Resource (lignes 12 et 22). Ces composants sont raffinés à partir de la ligne 12 notamment pour préciser le type de la donnée en entrée (ligne 17 : raffinement du prototype resource_type du composant Get_Resource).