Chapitre 3 : Notation COMM
2 Définition de la notation COMM
2.2 Spécification de l’interaction multiutilisateur
2.2.2 Notre solution
Les limites en termes de spécification des activités coopératives et collaboratives que nous avons illustrées dans la sous-section précédente ont pour conséquences principales d’augmenter la taille des spécifications et de compliquer la tâche du concepteur qui doit revisiter ses descriptions et représenter la collaboration sous la forme de coopération. Face à ce constat, nous proposons une solution qui s’articule en plusieurs points :
• Tout d’abord, nous proposons d’introduire un nouveau type de tâche plus générique : les
tâches multiutilisateurs afin de remplacer et d’englober les tâches coopératives et les tâches collaboratives.
• Ensuite, il s’agit d’associer pour chaque tâche le ou les rôles qui peuvent la réaliser, et de
compléter cette description par le nombre d’utilisateurs qui peuvent jouer ces rôles.
• Enfin, nous introduisons le concept de rôle interactif en contraste des rôles que l’on peut
qualifier de rôles métiers présents dans les notations existantes.
Ces trois points qui constituent notre solution pour décrire l’interaction multiutilisateurs sont détaillés dans les trois sous-sections suivantes.
2.2.2.1 Tâche multiutilisateur
Outre la difficulté à spécifier finement la tâche (comme l’illustre la Figure 80 par exemple), le problème est que la spécification obtenue sera exploitée pour la réalisation logicielle de l’application.
Créer un soldat Sélectionner un baraquement Créer un soldat Chef Gérer un baraquement ? Coopérative [] Chef Sergent Sergent Confirmer Chef Sélectionner un baraquement Confirmer Chef
163
Chapitre 3 : Notation COMM
Or si les tâches sont dupliquées pour décrire la collaboration sous la forme de coopération, cela peut conduire :
• soit à une application développée avec des portions redondantes, pour respecter la
spécification,
• soit un travail supplémentaire pour factoriser la spécification avant de la développer.
Dans les deux cas, cela implique un effort supplémentaire lors des phases de conception logicielle. De plus, lors de la conception logicielle, la nature coopérative ou collaborative d’une tâche n’a pas grande importance. En effet, lors du développement, il s’agit de savoir quel rôle donne accès à quelles fonctionnalités, c'est-à-dire à quelles tâches. Ainsi, lors d’une activité multiutilisateur, il s’agit de savoir quels rôles peuvent y participer, c'est-à-dire quels rôles peuvent réaliser les tâches qui la décrivent. La nature coopérative ou collaborative de la tâche n’a pas d’importance pour le développement. Il nous apparaît donc comme inutile de décrire explicitement la nature coopérative ou collaborative d’une tâche pour des spécifications devant servir de référence au développement. Nous proposons donc d’éviter aux concepteurs de modéliser la nature de la tâche afin qu’ils se concentrent sur la question des rôles pouvant les réaliser. Ainsi, nous introduisons le concept de tâche multiutilisateur qui est une tâche pouvant être réalisée par un ou plusieurs utilisateurs. Une tâche multiutilisateur n’implique aucune hypothèse quant à la nature coopérative ou collaborative de la tâche. La décomposition en sous-tâches et les décorations de la notation, tels que les rôles assignés aux tâches renseignent sur la nature coopérative ou collaborative sans qu’il soit utile de le préciser explicitement. En introduisant le concept de tâche multiutilisateur, nous supprimons également le concept de tâches coopératives. La Figure 81 illustre les éléments de la notation COMM après l’introduction de ce nouveau type de tâche : les tâches multiutilisateurs, et la suppression des tâches coopératives.
Lors de l’utilisation de la notation CTT [Mori 2002], la coopération est décrite au sein d’un arbre de tâches coopératives et les tâches individuelles associées à chaque rôle sont décrites dans un arbre spécifique (un par rôle). Cette décomposition en plusieurs arbres est moins pratique pour décrire la collaboration, puisque les sous-tâches individuelles ne sont associées à aucun rôle. Aussi, nous proposons de décrire toutes les tâches au sein d’un arbre de tâches unique qui comporte aussi bien des tâches individuelles que multiutilisateurs (correspondant elles-mêmes à des tâches coopératives ou collaboratives).
Pour conclure cette section, les trois amendements à notre notation (Figure 81) sont :
1. La suppression du type de tâche : coopérative
2. L’ajout du type de tâche : multiutilisateur
3. La spécification de l’interaction au sein d’un arbre unique (au lieu d’un arbre coopératif
Figure 81 : Eléments de la notation COMM après l’introduction de la tâche multiutilisateur.
2.2.2.2 Rôle métier et nombre d’utilisateurs
Dans la plupart des notations actuelles, y compris CTT [Mori 2002], seules les tâches feuilles d’un arbre de tâches peuvent être associées à un rôle. La notation CIAN [Molina 2006] introduit une nuance pour les arbres de tâches collaboratives. Il s’agit de décrire au niveau de la tâche collaborative de plus haut niveau, les rôles qui peuvent participer à la collaboration.
Nous avons choisi de ne pas utiliser de tâche explicitement collaborative, cependant, assigner des rôles à un autre niveau que celui des tâches feuilles est pertinent pour trois raisons :
1. La première raison est la capacité de factorisation que cela induit. Celle-ci est illustrée à la
Figure 82. Considérons une tâche T décomposée en deux sous-tâches T1 et T2 associées au
Rôle 1. Une factorisation simple permise avec l’association de rôle à une tâche non-feuille
consiste à associer le Rôle 1 directement à la tâche T plutôt qu’aux deux sous-tâches.
Figure 82 : Factorisation de la distribution des rôles dans un arbre de tâche.
2. La deuxième raison est le renforcement de l’approche descendante (top-down) qu’introduit
la spécification d’un arbre de tâches. En effet, spécifier un arbre de tâche consiste à décrire une tâche de très haut niveau d’abstraction, qui est raffinée successivement en sous-tâches jusqu’au niveau des tâches concrètes. Associer des rôles aux tâches de haut niveau d’abstraction permet donc de se poser en amont de l’interaction concrète la question de la répartition des tâches. Cette répartition se prolonge tout au long des raffinements successifs jusqu’au niveau des tâches concrètes comme l’illustre la Figure 83. A la première étape, le
concepteur associe les rôles R1 et R2 à la tâche racine T. Lors de la deuxième étape, le
concepteur décompose la tâche T en deux sous-tâches : T1 et T2, puis leurs associe le rôle R1
à T1 et les rôles R1 et R2 à T2. Lors de la troisième étape, il/elle décompose la tâche T2 en
deux sous-tâches, T2.1 et T2.2, auxquelles il/elle associe respectivement les rôles R1 et
T1 Rôle 1 T T 2 Rôle 1 T1 Rôle 1 T T 2 Factorisation Types de tâche Structure d’un arbre
T1 T1.2 T1.1 Type de tâche Opérateur unaire Opérateur binaire Nom de tâche Utilisateur Interactive Système Abstraite Multiutilisateur
165
Chapitre 3 : Notation COMM
R2.L’association des rôles s’effectue de manière continue et cohérente lors des raffinements
successifs.
Figure 83 : Association des rôles aux tâches à chaque étape du raffinement en sous-tâches.
3. Enfin, associer des rôles à des tâches non feuilles permet de préciser quel est le nombre
d’utilisateurs qui jouent un rôle donné. En effet, si nous reprenons l’exemple de la tâche
Gérer les troupes de l’application WCCM avec plusieurs utilisateurs jouant le rôle de Sergent
et un seul utilisateur jouant le rôle de Chef, nous pouvons décrire simplement la présence de
deux utilisateurs jouant le rôle Sergent. La Figure 84 reprend la modélisation de cette tâche,
initialement proposée à la Figure 75, adaptée aux amendements proposés. Ainsi, la tâche
gérer les troupes est associée à un ou deux utilisateurs jouant le rôle de Sergent et à un
utilisateur jouant le rôle de Chef. Les sous-tâches Déplacer un soldat et Former un groupe
sont associées à un utilisateur jouant le rôle de Sergent. Enfin, la tâche Déplacer un groupe
est associée au rôle de Chef.
Figure 84 : Tâche gérer les soldats avec la spécification des rôles et du nombre d’utilisateur.
Néanmoins, la description des rôles et des utilisateurs à tous les niveaux ne présente pas que des avantages. En effet, cela implique pour le concepteur de se poser la question pour chaque tâche : quels sont les rôles pouvant la réaliser, et combien d’utilisateurs peuvent jouer chaque rôle. Pour une application de grande taille, cela peut être fastidieux. Aussi, cette étape dans la spécification est optionnelle si le concepteur juge qu’il n’y a pas d’ambiguîté.
Former un groupe Déplacer un soldat
Gérer les troupes
Déplacer un groupe
1 Sergent 1 Sergent 1 Chef
1 – 2 Sergent, 1 Chef T1 R1, R2 T T2 R1, R2 R1 R2 R1 T2.1 T2.2 T1 R1, R2 T T2 R1, R2 R1 R1, R2 T
Figure 85 : Eléments de la notation COMM après l’introduction des rôles et du nombre d’utilisateurs pour les tâches.
2.2.2.3 Rôle interactif
L’analyse des différentes notations montre que la structuration de l’activité de groupe repose sur la notation de rôle métier. Cette approche est restrictive, en particulier pour les tâches collaboratives. En effet, pour ces dernières, il est nécessaire de se placer du point de vue de l’utilisateur. Nous nous focalisons ici sur un utilisateur et non un rôle comme à la section précédente.
L’usage d’une tâche multiutilisateur autorise la décoration de celle-ci par plusieurs rôles comme l’illustre la Figure 83. L’approche descendante décrire dans la section précedente a pour conséquence de générer un arbre dont les feuilles sont décorées avec un seul rôle. La répartition des tâches en fonction des rôles est alors figée dès la conception et ne laisse aucune souplesse lors de l’exécution. Il s’agit alors d’une tâche nécessairement coopérative et nous avons montrée les limites d’une telle approche.
Une tâche collaborative est au contraire opportuniste et la répartition ne peut être figée au moment de la conception. Cette répartition se fait à l’exécution et est décidée par les utilisateurs jouant les rôles associés à la tâche collaborative. Aussi, ce type de situation peut être décrit si l’on raisonne en termes d’utilisateur, et non plus en termes de rôle. Pour cela, nous proposons le concept de rôle interactif, en contraste au concept classique de rôle, que nous qualifions de rôle métier.
Une tâche T2 peut être décorée par un rôle interactif si celle-ci est une sous-tâche d’une tâche
multiutilisateur T1. Un rôle interactif est une décoration de tâche qui indique qu’un lien s’établit dynamiquement entre un utilisateur et un ensemble de tâche. Il permet d’indiquer l’association et l’exclusion dynamique de plusieurs tâches à un utilisateur donné. Un rôle interactif est associé à l’utilisateur lorsque celui-ci réalise une tâche qui est décorée par ce rôle. Le rôle reste lié à l’utilisateur jusqu'à ce que l’instance de la tâche mère se termine. Un utilisateur lié à un rôle interactif est alors le seul à pouvoir réaliser les autres tâches décorées par ce même rôle interactif.
Types de tâche Structure d’un arbre
T1 T1.2 T1.1 Type de tâche Opérateur unaire Opérateur binaire Nom de tâche Rôles métiers/utilisateurs
Rôles métiers/utilisateurs Rôles métiers/utilisateurs
Utilisateur
Interactive Système
Abstraite Multiutilisateur
Les opérateurs unaires et binaires ne sont pas reproduits ici pour des raisons de place.
Pour résumer, l’extension de notre notation (Figure 85) consiste à décrire pour chaque tâche le ou les rôles requis pour réaliser la tâche, ainsi que le nombre d’utilisateurs pouvant jouer ces rôles. Par défaut, lorsqu’un seul utilisateur jouant un rôle donné est requis, il n’est pas utile de préciser le nombre d’utilisateurs.
167
Chapitre 3 : Notation COMM
Ceci permet d’indiquer l’association dynamique d’un ensemble de tâches à un utilisateur donné. Par ailleurs, cet utilisateur ne peut pas réaliser une tâche décorée par un rôle interactif différent, permettant d’exclure dynamiquement un utilisateur de la réalisation d’un ensemble de tâches données.
Nous illustrons à la Figure 86 l’usage de rôle interactif pour la tâche multiutilisateur : Gérer un
baraquement. Elle est associée à un rôle métier de Sergent et un rôle métier de Chef, ce qui signifie que deux utilisateurs sont requis pour la réaliser. Nous décrivons trois sous-tâches : les tâches
Sélectionner un baraquement et Créer un soldat qui sont associées à un rôle interactif <Créateur> et
la tâche Confirmer qui est associée à un rôle interactif <Validateur>.
Figure 86 : Utilisation de rôle interactif pour décrire la tâche de gestion d’un baraquement.
L’arbre de tâches de la Figure 86 signifie que lorsqu’un utilisateur (jouant soit le rôle métier de
Sergent, soit le rôle métier de Chef) réalise la tâche Sélectionner le baraquement, il devient le seul à
pouvoir réaliser la tâche Créer un soldat. En effet, lorsqu’il sélectionne le baraquement, le rôle
interactif de <Créateur> lui est dynamiquement assigné. La tâche Créer un soldat étant décorée
également par ce rôle interactif, il devient le seul à pouvoir la réaliser. De la même manière, cet
utilisateur ne pourra pas réaliser la confirmation de la création du soldat. En effet, la tâche Confirmer
est décorée du rôle interactif <Validateur>, alors que l’utilisateur est devenu un <Créateur> pour
cette instance de tâche Gérer un baraquement. Seul l’autre utilisateur pourra donc réaliser la tâche
Confirmer. S’il le fait, le rôle de <Validateur> lui est dynamiquement assigné jusqu'à la fin de l’instance en cours de la tâche Gérer un baraquement, c'est-à-dire, juste après qu’il a réalisé la tâche
de confirmation. En effet, la tâche Gérer un baraquement étant considérée comme réalisée,
l’assignation dynamique des rôles interactifs aux deux utilisateurs est rompue. Une autre instance de
la tâche Gérer un baraquement peut alors être commencée pour peu qu’un des deux utilisateurs
décide de sélectionner le baraquement et de devenir ainsi un <Créateur>.
La comparaison de la Figure 86 avec la Figure 80 souligne la concision qu’apporte l’utilisation de rôle interactif à la spécification. Dans ce cas précis, cela permet de décrire une tâche collaborative complexe, sans recourir à la duplication de tâches ou à l’introduction de tâche abstraite supplémentaires. Les décorations sous forme de rôle interactif suffisent.
Outre la concision de la spécification, considérons un autre exemple pour illustrer le pouvoir d’expression du rôle interactif.
Considérons le cas où le concepteur souhaite que seul l’utilisateur jouant le rôle métier de Chef
puisse réaliser la confirmation. La spécification conserve la même forme et ne subit qu’une
modification des décorations de tâches, comme l’illustre la Figure 87. La tâche Confirmer perd alors
Créer un soldat Sélectionner un baraquement
Gérer un baraquement soldats
Confirmer
<Créateur> <Créateur> <Validateur>
Sergent, Chef
son rôle interactif de <Validateur> et est décorée du rôle métier de Chef. La spécification indique
comme précédemment qu’un utilisateur (soit le Sergent, soit le Chef) peut réaliser les deux
premières sous-tâches, tandis que seul l’utilisateur jouant le rôle métier de Chef peut réaliser la
confirmation.
Figure 87 : Utilisation conjointe de rôle métier et de rôle interactif pour la tâche de gestion d’un baraquement.
Figure 88 : Eléments de la notation COMM après introduction du concept de rôle interactif.