Chapitre 7 Traces d’activité conjointes
7.2 Systèmes à Base de Traces modélisées conjointes
7.2.2 Les traces modélisées d’activités conjointes
Avant de rentrer dans le détail de notre proposition d’extension des Systèmes à Base de Traces
modé-lisées, nous souhaitons revenir sur la justification de notre démarche. En effet, rien n’indique a priori
qu’un utilisateur quelconque soit susceptible d’exploiter les traces modélisées d’un autre utilisateur, ni même qu’il aurait intérêt à le faire dans le cadre d’une activité conjointe. Or, dans le cadre de notre expérimentation (terrain d’application sur la production de formations), nous avons pu constater qu’un développeur était capable d’objectiver son activité par l’interprétation d’une trace modélisée même sans réussir à se la réapproprier totalement, ce qui indiquerait qu’il pourrait faire de même avec
l’activité d’un autre développeur – d’autant plus si l’activité en question les impliquait tous les deux.
De plus, l’intérêt du partage de la trace modélisée de l’activité passée est ici évident puisque les deux acteurs en question n’ont été capables de se remémorer leur activité conjointes que lors d’un échange en face à face permettant de confronter leurs souvenirs et documents respectifs. Il nous paraît donc tout à fait pertinent de tenter d’instrumenter l’ensemble des situations d’usages conjoints qui pourrait naître de la mise à disposition d’un Système à Base de Trace conjointe.
7.2.2.1 Notion de sujet d’une trace modélisée
Nous ne proposons ici qu’une extension du cadre conceptuel des Systèmes à Base de Traces
modéli-sées (présenté au Chapitre 3) ce qui signifie que nous en conservons les principaux concepts et que nous les adaptons au contexte des activités conjointes. Sur le plan conceptuel, l’apport essentiel réside
dans l’introduction de la notion de sujet de la trace. On peut décrire ce sujet comme un méta-donnée
ajoutée à une trace modélisée caractérisant la situation d’observation et par extension chaque observé de la trace. De manière générique, nous considérons que le sujet sera un simple identifiant, ou ensem-ble d’identifiants, et ne prenons pas position sur le fait que cet identifiant désigne une personne à un moment donnée ou bien cette personne dans une situation donnée ou encore la même personne sur plusieurs situations différentes.
7.2.2.2 Formalisation et nouvelle définition des observés
Nous avons choisi de formaliser la notion de sujet au niveau de chaque observé, ce qui simplifie la description des traces modélisées constituées d’observés provenant de différentes situations
d’observation. Formellement, on définit un sujet comme un identifiant ou un ensemble de sujets. La
récursivité de la définition du sujet permet à une trace ou un observé de porter sur un groupe
(explici-te) d'acteurs. L'identifiant peut ainsi représenter soit un acteur individuel : une personne, ou un acteur
artificiel ; soit un acteur groupe : un groupe de personnes considéré comme une entité opaque
(réifica-tion ou personnifica(réifica-tion du groupe), voire même un ensemble de groupes (exemple : l'ensemble com-posé de deux équipes, elles mêmes comcom-posées de plusieurs personnes).
Dans le cadre conceptuel des SBTm « classique » nous avons défini un observé comme toute informa-tion structurée issue de l’observainforma-tion d’une interacinforma-tion (secinforma-tion 3.3.1.1). Désormais, dans le cadre des
Système à Base de Traces Conjointes, tout observé est donc associé à un sujet. Du coup, le sujet de la
trace est lui-même déduit en « agrégeant » les sujets des observés qui la composent. Il existe plusieurs manières de faire cette agrégation. Il est possible de faire notamment l’un des deux calculs suivant : soit le sujet d’une trace est simplement « constitué » de l’ensemble des sujets de ses observés ; soit le sujet est le résultat de l’union ensembliste des sujets des observés. Considérons une trace dont les ob-servés ont respectivement pour sujets {a,b}, {c,d} et a. Le premier calcul donnera pour sujet de la trace l'ensemble {{a,b}, {c,d}, a} ; le second donnera pour sujet {a, b, c, d}. De cette formalisation
découle un dédoublement du concept de trace modélisée, en trace modélisée individuelle et trace
mo-délisée conjointe
7.2.2.3 Traces modélisées « individuelles » et traces modélisées « conjointes »
Trace modélisée individuelle
Nous définissons une trace modélisée individuelle comme une collection structurée et pourvue d’une
extension temporelle, d’observés temporellement situés issus de l’observation de l’utilisation d’un système observé par un acteur dans le cadre d’une activité donnée. Une trace modélisée individuelle
est générée par l’instanciation d’un modèle de trace individuelle explicite et contient l’identificationde
l’acteur concerné. Cette définition est identique à celle d’une trace modélisée « classique » à ceci près qu’il est obligatoire que ses observés (et donc elle-même) permettent explicitement l’identification de l’acteur qui interagit avec le système observé depuis sa machine.
Trace modélisée conjointe
Sur la base de ce qui précède nous pouvons désormais proposer la définition suivante de ce que nous appellerons une trace modélisée conjointe : dans le cadre de l’utilisation par au moins deux acteurs
distincts d’un système observé au cours d'une activité conjointe donnée, une trace modélisée conjointe
est définie comme une collection, pourvue d’une extension temporelle, d’observés temporellement situés, associée à un modèle de trace conjointe explicite, telle que deux ensembles d’observés liés aux deux acteurs distincts puissent y être distingués. La notion de trace modélisée conjointe implique un lien constitutif201 à au moins deux traces modélisées individuelles, correspondant aux deux acteurs distincts considérés, dont les observés constituent les traces modélisées individuelles. Deux types de
traces modélisées conjointes peuvent être distingués (Figure 7.3) :
- Une trace modélisée conjointe croisée est constituée de l’ensemble des observés attribués à l’un ou l’autre des acteurs impliqués (observés), elle permet de décrire une utilisation « croisée » de
l’environnement, c’est-à-dire par au moins deux utilisateurs distincts.
Dans le cas d’une trace conjointe « croisée » le modèle d’une trace modélisée conjointe MTC sera
soit le modèle commun aux traces individuelles MTI des acteurs, soit l’union de plusieurs modèles
de trace individuelle différents MTC = ∪ MTIi.
201 Soit par construction de la trace conjointe à partir des traces individuelles, soit parce qu’on peut retrouver des traces individuelles dans la trace conjointe.
- Une trace modélisée conjointe enrichie est construite à partir d’une trace conjointe croisée com-plétée d’observés non liés aux acteurs de l’activité conjointe, mais liée au groupe d’acteurs lui-même considéré comme acteur.
Dans le cas d’une trace conjointe « enrichie » cette fois, le modèle MTC sera le modèle de la trace
conjointe croisée complété d’un modèle d’enrichissement, correspondant à l’acteur groupe MTC = ∪ MTIi + MTG.
Figure 7.3 : (a) Deux traces modélisées individuelles, (b) une trace conjointe croisée, (c) une trace conjointe enrichie.
7.2.2.4 Remarque sur l’implémentation d’un Système à Base de Traces conjointes
Les différentes opérations que nous venons d’évoquer et qui sont intrinsèquement liées à la définition des traces conjointes202 devront être réalisées selon la situation dans des configurations relativement différentes. La gestion des différents modèles de traces et des transformations afférentes au croisement ou à l’enrichissement d’une trace conjointe doit être réalisée notamment en fonction de l’architecture concrète du système observé implémenté. L’extension conceptuelle qui introduit simplement la notion
de sujet engendre par ailleurs un besoin d’extension du framework informatique qui est encore en
cours de développement. La première difficulté sera rencontrée dans le processus de collecte. Il s’agit par exemple de vérifier, en fonction d’architectures diverses, qu’il sera toujours possible de générer une trace modélisée conjointe croisée. Nous décrivons donc, ci-dessous, trois configurations de collec-te en fonction d’archicollec-tectures typiques rencontrées dans des situations d’activités conjoincollec-tes instru-mentées.
Collecte serveur (modèle de trace conjointe « unique »)
Une première situation possible est celle d’une activité conjointe pour laquelle tous les acteurs exploi-tent une même application serveur. En principe, toute action réalisée est enregistrable directement depuis ce dernier, ce qui permet d’envisager une collecte directement sur le serveur en question. Dans
ce cas l’obtention d’une trace conjointe croisée203 peut s’appuyer sur un unique modèle de trace
per-mettant de générer directement une trace conjointe croisée, une trace conjointe enrichie étant alors
obtenue par transformation de cette dernière.
202 Pour alléger le texte nous parlerons de « trace conjointe » ou de « trace individuelle » pour désigner respectivement une trace « modélisée » conjointe et une trace « modélisée » individuelle.
Figure 7.4 : Collecte serveur.
Collecte client (modèles de trace individuelle identiques ou différents)
La seconde situation, à l’opposée de la première, est celle où l’activité passe par l’exploitation d’un environnement client pour chaque acteur. L’environnement local de chaque acteur constituant l’unique source de traçage, la collecte s’effectue donc du côté client, en respect d’un modèle de trace indivi-duelle. Deux cas sont alors à envisager : soit les modèles de trace conjointe sont identiques, soit ils ne le sont pas. Pour obtenir une trace conjointe croisée, il est dans ce cas nécessaire de centraliser les traces modélisées individuelles et de passer par un modèle pivot permettant de la générer : dans le cas d’un modèle de trace individuelle identique pour tous les acteurs, il s’agira simplement de fusionner les différentes traces (sur la base d’un alignement de l’extension temporelle) ; dans le cas de modèles de trace individuelle différents, le modèle pivot devra en faire l’union afin d’obtenir la trace conjointe croisée recherchée.
Figure 7.5 : Collecte client.
Collecte mixte (modèles de trace individuelle identiques ou différents)
Sachant que dans beaucoup de situations de traçage, il est nécessaire d’observer à la fois l’utilisation d’un environnement côté client et côté serveur, la troisième situation qui est l’association des deux précédentes, sera sans doute la plus courante. Il s’agit d’une situation où les acteurs utilisent une appli-cation client-serveur qui constitue une « double » source de traçage. La collecte s’effectue alors à la fois côté serveur (avec un modèle de trace unique) et du côté client (avec des modèles de trace indivi-duelle identiques ou différents selon les acteurs). Pour obtenir une trace conjointe croisée, il est néces-saire de centraliser les traces individuelles collectées côté client et celles collectées côté serveur. Dans le cas de modèles de trace individuelle identiques, il s’agit de générer une trace individuelle pour chaque acteur à partir de la double collecte (client + serveur), puis de procéder comme précédemment (« fusion » des différentes traces individuelles). Dans le cas de modèles différents, il est nécessaire de passer par un modèle pivot qui réalise l’union des différents modèles de traces individuelles.
Figure 7.6 : Collecte mixte.
Loin de nous l’idée d’avoir, à travers ces trois situations caricaturales (et leur variantes), couvert l’ensemble des difficultés rencontrées pour la mise en place d’une fonction de collecte répondant aux
contraintes imposées par une extension du framework informatique des SBTm aux traces modélisées
conjointes. Des architectures plus complexes, par exemple Peer-to-Peer, demandent encore à être
étudiées. Notre objectif n’étant toutefois pas de dresser la liste de ces contraintes techniques mais de souligner la complexité d’une implémentation d’un Système à Base de Traces conjointes, nous allons pour terminer ce chapitre nous intéresser aux multiples usages des traces conjointes que permettent désormais d’instrumenter un Système à Base de Traces conjointes.