• Aucun résultat trouvé

CHAPITRE 01 : LANGAGES DE DESCRIPTION D’ARCHITECTURE ET INGENIERIE DIRIGEE PAR

1. Rapide

Rapide [LUC95] a pour but initial de vérifier par la simulation la validité d’une architecture logicielle donnée. Une application est construite sous la forme de modules ou composants communiquant par échange de messages ou évènements. Le simulateur associé à Rapide permet ensuite de vérifier la validité de l’architecture. Les concepts de base du langage Rapide sont les événements, les composants et l’architecture.

1.1. Evénements

Le concept de base de Rapide est l’événement qui est une information transmise entre composants. L’événement permet de construire des expressions appelées Event patterns. Ces expressions permettent de caractériser les évènements circulant entre les composants. Par exemple, si A et B sont des

Page 36

événements, A>B signifie que B sera envoyé après A. La construction de ces expressions se fait par l’utilisation d’opérateurs qui définissent les dépendances entre événements. L’ensemble de ces opérateurs est répertorié dans le tableau suivant :

opération sémantique

A > B B est envoyé après A A -> B B dépend causalement de A

A || B A et B ne sont pas causalement dépendants A ~ B A et B sont différents

A and B A et B sont vérifiés simultanément

Figure 1.1. Expressions d’événements dans Rapide

1.2. Composants

Le composant est défini par une interface. Cette dernière est constituée d’un ensemble de services fournis et d’un ensemble de services requis. Les services sont de trois types :

• les Provides peuvent être appelés de manière synchrone par les composants,

• les Requiers sont les services que le composant demande de manière synchrone à d’autres composants. Un composant peut donc communiquer de manière synchrone avec un autre composant si leurs services requiers et provides sont connectés,

• les Actions correspondent à des appels asynchrones entre composants. Deux types d’actions existent : les actions in et out qui correspondent respectivement à des événements acceptés ou envoyés par un composant.

L’interface contient également une section de description du comportement (clause behavior) du composant. Cette dernière correspond au fonctionnement observable du composant, par exemple l’ordonnancement des événements ou des appels aux services. C’est grâce à cette description que Rapide est en mesure de simuler le fonctionnement de l’application.

De plus, Rapide permet de spécifier des contraintes (clause constraint) qui sont des patrons d’évènements qui doivent ou non se produire pour un composant lors de son exécution. Par exemple, une contrainte peut fixer un ordre obligatoire pour une séquence d’événements d’un composant. En général, ces contraintes permettent de spécifier des restrictions sur le comportement des composants.

Une application est représentée par son architecture. Une architecture consiste en des déclarations d’instances de composants, des connexions entre ces instances et des contraintes sur le comportement de l’architecture. Voici la structure d’une architecture :

Page 37 ArchitectureName is // Déclarations Connections // Connexions [constraints] // Contraintes optionnelles EndName

Les connexions entre les instances de composants sont régies par des règles. Une règle d’interconnexion est composée de deux parties. La partie gauche contient une expression d’événements qui doit être vérifiée. La partie droite contient également une expression d’événements qui doivent être déclenchés après la vérification de l’expression de la partie gauche. L’exemple suivant illustre ces règles :

With Client, Serveur ; …

// Déclaration des instances de composants de l’application susceptible d’exister ?s : Client ; // Fait référence à une instance de Client

?r : Serveur ; // Fait référence à toutes les instances de Serveur

?d : Data ; // Fait référence à un bloc de paramètres d’un certain type Data

// Une régle d’interconnection

?s.Send( ?d) => !r.Receive( ?d) ;

// Si un client transmit un événement de type Send avec ce type de paramètres, alors l’évènement est transmis à tous les serveurs de l’application avec ces paramètre.

1.3. Evaluation

Rapide prend en compte différents modèles d’exécution. Pour cela, il offre, au niveau de l’interface des composants, des appels de service synchrones et asynchrones et utilise plusieurs opérateurs d’interconnexion. De plus, Rapide offre le moyen d’éviter l’installation et le déploiement d’une application de taille importante pour réaliser les tests de validité de l’architecture. En effet, sous Rapide, la simulation d’un modèle génère un ensemble d’événements qui apparaissent à l’exécution avec des relations causales et temporelles.

Rapide permet d’exprimer une caractéristique importante et intéressante : la dynamique d’une application, grâce à l’utilisation de règles d’interconnexion déclenchées par le comportement des composants logiciels au moment d’un changement d’état par exemple. Cette dynamique est exprimée sous la forme d’ensembles d’instances de composants ou de règles d’interconnexion évoluant selon le comportement des composants. Le langage Rapide ne prend pas en compte la notion de connecteur « statique » et ne permet pas ainsi de représenter un connecteur comme une entité de premier degré.

Avec Rapide, il n’est pas possible de reconfigurer une application du fait de l’inexistence d’opérateurs de création, de suppression, de migration de composants et de modification d’interconnections. De plus, Rapide est un langage qui ne propose pas d’éléments de structuration de l’application.

Page 38

Enfin, Rapide est basé sur un formalisme de description qui permet des vérifications statiques et dynamiques de l'exécution d'une application. Cette caractéristique est particulièrement appréciable dans le cas d'architectures de grande taille à forte complexité car elle évite l'installation et le déploiement d'une application pour effectuer les tests de validité de l'architecture.

Le tableau 1.1 résume les avantages et les inconvénients de l’ADL Rapide :

Avantage

• Rapide permet d’exprimer la dynamique d’une application de manière précise et détaillée ;

• Il est possible de simuler une application grâce à la création d’événements causals et grâce à l’environnement d’exécution intégrée à l’ADL.

• Il permet le raisonnement formel sur l’architecture

Inconvénient

• Rapide ne permet pas de générer le code d’une application. Son but est avant tout de vérifier la validité des architectures par des techniques de simulation de l'exécution.

• Non prise en compte de la vérification de la compatibilité entre composants lors de l’assemblage.

• Il n’y a pas de représentation explicite de connecteurs.

TABLE 1.1. AVANTAGES ET INCONVENIENTS DE RAPIDE