Exemples de compositions d’interactions

Afin de donner une vue intuitive du domaine et de son utilisation, nous présentons un exemple simple et usuel de gestion d’agendas. Cette application est composée d’une classe de composants Display qui permet l’affichage de message, d’une classe de com-posants SecurityManager qui permet de valider des appels, d’une classe de comcom-posants simplifiée Database qui permet de mémoriser les agendas dans une table de hachage en fonction du nom de l’utilisateur de l’agenda et une classe de composants Agenda. En cours d’exécution, les instances de ces différentes classes de composants sont liées et déliées par des interactions pour s’adapter au contexte d’exécution (création d’un nou-veau composant de groupe, ajout d’un membre dans l’équipe, nécessité de sécurité lors de la mise en réseau, ajout d’une base de données,. . . ). Ainsi certains composants Agenda sont rendus persistants, un agenda de groupe est créé par la pose d’interactions entre plusieurs agendas, un authentificateur est associé à certains agendas pour vérifier que seuls les utilisateurs autorisés accèdent à l’agenda. La figure6.1visualise un réseau de composants et d’interactions à un moment donné de l’exécution de l’application.

2. L’introduction d’un nouvel ordre entre des activités serait soit basé sur l’ordre des déclarations, soit basé sur l’utilisateur ce qui suppose une connaissance de toutes les interactions ; Ces différentes approches nous semblent contradictoires avec la séparation des préoccupations.

FIGURE6.1: GRAPHE D’INTERACTIONS POUR L’APPLICATIONAGENDA

Définition d’un schéma d’interactions L’utilisateur exprime les schémas d’interac-tions en utilisant le Langage de Spécification des Interacd’interac-tions : ISL (cf. figure6.2pour un exemple) qui est décrit plus amplement dans [BFCE+04]. Au travers de ces exemples nous en donnons une définition intuitive. Un schéma décrit plusieurs règles d’interac-tions qui expriment les contrôles qui doivent être opérés sur les composants liés. Une règle est composée d’une partie gauche qui exprime le modèle de message que l’on veut contrôler et d’une partie droite, l’activité qui correspond à la réécriture du message iden-tifié à gauche de la règle. Un message correspondant au modèle en partie gauche est dit "notifiant". Lors de l’instanciation du schéma, il sera identifié relativement aux opéra-tions des composants liés.

Par exemple, le développeur de l’application d’agendas veut autoriser ses utilisateurs à lier à l’exécution un agenda à un " afficheur " afin d’être notifié chaque fois qu’un rendez-vous est ajouté dans l’agenda. Pour les agendas, il peut être utile de gérer la persistance par stockage dans une base de données définie par l’utilisateur. Pour cela, le développeur définit des schémas d’interactions qui sont fournis avec l’application (cf. figure6.2, schémas notification et persistence). Ces schémas pourront être instanciés par l’utilisateur final pour lier des composants, nous parlons alors de la pose d’interaction. En cours d’exécution, un utilisateur des agendas peut vouloir lier des agendas, interac-tion non prévue par le développeur de l’applicainterac-tion, pour par exemple créer des agendas de groupe. De la même manière que précédemment, il définit alors son propre schéma d’interactions (cf. figure6.2, schéma group).

Pose, composition et retrait d’interactions Lors de l’utilisation de l’application d’agendas, plusieurs schémas d’interactions sont instanciés.

6.1. Domaine applicatif et objectifs 93

Syntaxe L’exécution du message notifiant lui-même est notée _call. La réification du message peut être passée en argument, elle est notée _reifiedCall. L’exécution non ordonnée de deux envois de messages est noté //, alors qu’une exécution en séquence est notée ;. Une synchronisa-tion entre plusieurs activités est notée en étiquetant l’activité par [n] et en notant l’attente de fin de cette activité par _[n].

Le schéma notification (ligne 1) peut lier deux composants. Il contient une règle (ligne 2). Elle exprime que tout message (utilisation de l’étoile) reçu par un objet ainsi lié, peut être exécuté dans un ordre quelconque avec l’envoi de message au composant display associé qui prend en paramètre la réification de l’appel. Le schéma group (ligne 6) peut lier 3 composants. Il définit deux règles. La pre-mière stipule que le message addMeeting des agendas correspondant au para-mètre team entraînera après l’exécution du message lui-même (ligne 8), l’ajout du rendez-vous à l’agenda du membre.

a) L’instanciation du schéma d’interactions group entre les agendas RainbowAgenda et MireilleAgendaet TeamDisplay conduit entre autre à modifier le comportement du com-posant MireilleAgenda et en particulier l’opération addMeeting.

b) L’instanciation du schéma d’interactions security entre l’agenda MireilleAgenda et SecurityManager modifie à son tour l’opération addMeeting. Une composition des in-teractions est alors réalisée. Elle a pour conséquence qu’ajouter un rendez-vous dans l’agenda de Mireille correspond à vérifier que cet appel est autorisé et si c’est le cas, à ajouter effectivement le rendez-vous dans l’agenda, puis à notifier l’afficheur. Dans le cas contraire, une exception est levée et l’afficheur n’est pas notifié.

Nous obtenons alors l’interaction suivante sur l’opération addMeeting de MireilleA-genda : MireilleAgenda . addMeeting ( s t r i n g p0 ) −> i f ( SecurityManager . check ( _ r e i f i e d C a l l ) ) { MireilleAgenda . _ c a l l ; TeamDisplay . n o t i f y ( _ r e i f i e d C a l l ) ; } e l s e { throw " UnauthorizedUser " }

c) Le retrait des interactions correspondant au schéma group entre les agendas Rainbo-wAgenda et MireilleAgenda et TeamDisplay (instanciée en a), consiste entre autres à retirer les modifications, décrites dans les règles lignes 7 et 11 de la figure 2, concernant l’opération addMeeting du composant MireilleAgenda. A présent, ajouter un rendez-vous dans l’agenda de Mireille correspond à vérifier que cet appel est autorisé et si c’est le cas, à ajouter effectivement le rendez-vous dans l’agenda, sans en notifier l’afficheur.

d) L’agenda de MireilleAgenda est lié à plusieurs composants (cf. figure6.1), voici l’inter-action résultante : MireilleAgenda . addMeeting ( s t r i n g p0 ) −> Display2 . n o t i f y ( _ r e i f i e d C a l l ) / / Display1 . n o t i f y ( _ r e i f i e d C a l l ) / / i f ( SecurityManager . check ( _ r e i f i e d C a l l ) ) ( MireilleAgenda . _ c a l l ; ; ( TeamDisplay . n o t i f y ( _ r e i f i e d C a l l ) ) / / ( owner : = ( MireilleAgenda . getOwner ( )

; ComposantBD . s tor e ( owner , Database ) ) ) e l s e {

throw " UnauthorizedUser " }