L’architecture de l’application est illustrée par la Figure5.10. En plus de l’outil MDE, chaque participant dispose d’un client de communication qui lui permet de se connecter au serveur Galaxy et de rejoindre des groupes de travail. Le serveur de communication gère les connexions des participants et leurs actions. Après chaque évènement, il notifie le framework de communi-cation et le framework de contrôle d’accès afin de déployer les composants logiciels nécessaires.
Client de communication
Le diagramme de classe, présenté dans la Figure5.11, montre les principales classes du client de communication de l’application. La classe principale est la classe Client. Elle permet l’initialisation de la partie client et fournit à la classeServerConnectionles informations de connexion telles que l’adresse IP
Figure 5.10–Architecture de l’application
et le port d’écoute du serveur. La classe ServerConnexion permet d’établir la connexion avec le serveur et d’échanger des messages à travers la classe
Comm_client_server. Les donnés relatives à l’utilisateur telles que ses rôles et les groupes auxquels il appartient sont gérées par la classe User. La classe
GUI fournit une interface graphique qui gère les connexions et les actions des utilisateurs. Nous avons utilisé la bibliothèque Swing qui fait partie de la bibliothèque JFC (Java Foundation Classes23
) pour la gestion des éléments graphiques de la partie client. La Figure 5.12 montre l’interface graphique du client de communication. Elle contient les informations de connexions telles que les rôles qui peuvent être choisis par l’utilisateur (à gauche) et les groupes auxquels il peut appartenir (à droite).
Figure 5.11–Classes principales du client de communication
Chaque participant utilise cette interface pour se connecter au serveur de communication. Une fois connecté, il peut activer un ou plusieurs rôles et choisir un ou deux groupes de travail (WorkGroupAetWorkGroupB). Après la validation du serveur, le participant peut désactiver un rôle en utilisant le boutonremoverole, activer un autre rôle en utilisant le boutonaddrole, chan-ger un rôle par un autre rôle en utilisant le bouton changerole, rejoindre un groupe en utilisant le bouton joingroup, ou bien quitter un groupe en utili-sant le bouton quitgroup. Il peut également quitter l’application en utilisant le bouton Quit.
Serveur de communication
Les principales classes du serveur de communication sont illustrées par la Figure5.13. La classeServerpermet de gérer les connexions des utilisateurs à travers la classe ClientConnection qui utilise la classeComm_client_server
Figure 5.12–Interface graphique du client de l’application
pour gérer les échanges de messages. La classeClientConnectionutilise éga-lement une classe ClientAuthentication afin gérer les authentifications des utilisateurs. La classe Model Manager permet de mettre à jour les instances de l’ontologie de domaine après chaque action d’un utilisateur. Elle repré-sente l’API que nous avons décrite dans l’étape2 de l’utilisation du frame-work de la section 3.3.4. La classe Model Manager contient également une fonctioninitialize()qui permet de charger les ontologies de domaine en uti-lisant l’API Protégé-OWL.
Figure 5.13–Classes principales du serveur de communication
Après chaque réception d’un message de la part d’un utilisateur, une ins-tance de la classeModel Managerse charge de mettre à jour l’instance de l’on-tologie de domaine. Ensuite, une instance de la classe FrameworkLauncher
est appelée afin d’exécuter le processus d’adaptation. Chaque processus d’adaptation finit par le déploiement des composants de communication et de contrôle d’accès dans les dispositifs des utilisateurs.
Protocole de communication
La communication entre le client et le serveur est basée sur les sockets qui permettent d’établir des canaux de communication suivant le protocole TCP ou UDP. Les sockets permettent l’échange de messages personnalisés sous la forme d’objets Java. Ce qui fait que le protocole de communication peut être représenté par un ensemble de classes où chaque classe correspond à un message échangé entre le client et le serveur. Ces classes sont représentées dans la Figure 5.14. Tous les messages héritent de la classe Message qui définit un attribut id représentant l’identifiant de chaque message. Chaque action de l’utilisateur est transformée en un objet de la classe correspondante qui sera envoyé au serveur de communication. Ceci est possible grâce au mécanisme de sérialisation en Java. Les objets de types Acknowledgement
sont envoyés par le serveur au client afin de lui notifier du résultat de sa requête.
Figure 5.14–Diagramme de classes des messages échangés entre le client et le serveur
5.4 Évaluation fonctionnelle
Dans cette section, nous présentons une évaluation fonctionnelle du fra-mework de contrôle d’accès et des techniques de déploiement que nous avons appliquées aux deux frameworks. En premier lieu, nous présentons le scénario qui consiste en un ensemble d’évènements. Ensuite, nous décri-vons l’interaction du serveur de l’application avec le framework de com-munication et le framework de contrôle d’accès après chaque évènement. Nous examinons également les résultats produits par les deux frameworks durant le déroulement du scénario. Les expérimentations que nous présen-tons dans cette sous-section nous permettent de valider le fonctionnement des processus d’adaptation dans plusieurs situations. Dans chaque situation, nous évaluons le comportement du framework de communication et du fra-mework de contrôle d’accès depuis le moment où le changement se produit jusqu’au déploiement ou reconfiguration physique des composants logiciels dans les dispositifs des utilisateurs. Cette évaluation nous permet de vérifier si les processus d’adaptation produisent les résultats attendus pour chaque situation.
5.4.1 Scénario
Afin d’évaluer les processus d’adaptation, nous présentons un scénario qui illustre plusieurs situations pouvant avoir lieu au cours de l’exécution de
l’application. Ce scénario est illustré dans le Tableau5.4. Il permet de suivre l’évolution de deux groupes de travail dans le temps. Durant le scénario, nous considérons les deux groupes de travail (workGroupAetworkGroupB), les rôles, les ressources et les politiques que nous avons introduits dans la section5.3. Dans le Tableau5.4, la lettre A désigne le groupeworkGroupA, et la lettre B désigne le groupe workGroupB. Dans le Tableau 5.5, nous rappe-lons les sessions associées à chaque groupe de travail ainsi que les rôles qui participent dans chaque session. Dans cette évaluation fonctionnelle, nous introduisons seulement trois utilisateurs dans le scénario afin de le rendre simple et clair. Cependant, nous considérerons plusieurs utilisateurs dans l’évaluation des performances.
Étape N Action Situation dans les groupes
1 John_Connect (Designers-Leader, A,B) A :John B :John 2 Bob_Connect (SimpleDesi-gner, A) A :John + Bob B :John 3 Tom_Connect (SimpleDesi-gner+TestDeveloper, B) A :John + Bob B :John + Tom 4 Bob_AddRole (Deployment-Manager) A :John + Bob B :John + Tom 5 Bob_RemoveRole (SimpleDe-signer) A :John + Bob B :John + Tom 6 Bob_ChangeRole (Deploy-mentManager, Integration-Manager) A :John + Bob B :John + Tom
7 Bob_JoinGroup(B) A :John + Bob B :John + Tom + Bob
8 Bob_Quit(B) A :John + Bob B :John + Tom
Tab.5.4–Scénario
Dans ce scénario, nous mettons en œuvre toutes les actions qui peuvent être effectuées par les utilisateurs durant l’activité collaborative. Le Tableau
5.4décrit huit étapes où chaque étape représente une action (ou évènement). Pour chaque action, nous montrons la situation des utilisateurs dans chaque groupe. Les actions ont la forme suivante : nomUtilisateur_Action(rôles, groupes) où nomUtilisateur représente le nom de l’utilisateur qui effectue l’action etAction(rles,groupes)représente l’action effectuée et les rôles et les groupes en question.
Groupe Sessions Rôles partici-pants
workGroupA Designers_Session Simple Designer, Designers Leader DesignerLead_Integrator_Session Designers Lea-der, Integration Manager
workGroupB Integrator_Developer_Session Integration Ma-nager, Code Developer, Test Developer
DesignerLead_Developer_Session Designers Lea-der, Code De-veloper, Test Developer
Tab.5.5–Sessions associées aux groupes