ORGANISATION DU DÉPLACEMENT

(a) Sauvegarde après chaque événement.

(b) Sauvegarde intermittente avec différences.

(c) Sauvegarde intermittente.

FIG. 3.1. – Trois possibilités de construction d’un film d’exécution (les barres de

couleur représentent les événements et les barres blanches ou grises au-dessus indiquent le volume données à sauver). En (b) on ne sauve l’état que de temps en temps et sinon on stocke la différence entre l’état actuel et l’état précédent ; en (c) on reconstruit normalement les états non sauvés à partir des événements.

1;000 4;000 7;000

8;500

(a) Déplacement en avant.

1;000

2;500

4;000 7;000

(b) Déplacement en arrière.

FIG. 3.2. – Déplacement dans le temps. Les instants où l’état de l’environnement

a été sauvé sont figurés par un symbole de fichier. Le dernier état sauvegardé à partir duquel les données sont traitées normalement est dessiné avec des tirets, de même que l’instant destination. On remarque que le sens du saut ne change rien à la manière dont est fait le déplacement dans le temps.

le graphe d’analyse (figure 3.2).

3.3.2 Mécanismes de sauvegarde et de restauration

Les mécanismes utilisés doivent être les plus simples possibles pour qu’ils ne soient pas eux-mêmes difficiles à mettre en œuvre et pour qu’ils soient aussi effi-caces que possibles. Le principe de la sauvegarde d’un état est le suivant : Scope crée un flux d’écriture typé (c’est-à-dire sur lequel on écrit les données dans un format permettant leur relecture sur une machine d’architecture différente) et de-mande à chacun des composants du programme visuel utilisé de sauvegarder son état dans ce flux. Les composants sont responsables du choix des données qu’ils enregistrent du moment que leur relecture permet la restauration de leur état à l’instant de la sauvegarde. Quant à la restauration d’un état, il s’agit simplement de rouvrir le flux correspondant à l’état à restaurer puis de demander aux compo-sants de relire les données qu’ils y avaient placé lors de la sauvegarde.

3.3. ORGANISATION DU DÉPLACEMENT

En fait les méthodes utilisées sont un peu plus complexes car il faut penser aux problèmes qui peuvent se présenter. Reprenons l’exemple d’un simulateur de Scope : par souci de portabilité et de facilité de manipulation par des outils standards, les fonctions de sauvegarde et de restauration de la bibliothèque de manipulation de graphes utilisée ont été conçues pour utiliser des fichiers de type texte et non des flux de données typés, qui n’existent pas sur tous les systèmes. (Il est certainement possible de tricher un peu et de s’arranger pour écrire le graphe dans un flux de données typé, par exemple en relisant chaque ligne du fichier texte avant de l’écrire dans le flux lors de la sauvegarde et même de recréer un fichier texte d’après ces données lors de la restauration, mais cela va à l’encontre de nos objectifs de simplicité et d’efficacité.) Le flux fourni par Scope est donc ouvert dans un répertoire dédié aux informations composant l’état de l’environnement, et ce répertoire peut être utilisé librement par les composants (sous contrainte de respecter certaines règles de partage de cet espace d’écriture). Dans notre exemple, le simulateur utilise donc un fichier texte comme le demande la bibliothèque de manipulation de graphes dont il se sert, et ne place dans le flux que le nom de ce fichier afin de pouvoir le retrouver pour restaurer son graphe d’état.

Considérons également le fait que le graphe d’analyse est un programme dont la structure n’est pas figée et qui peut être modifié à tout instant par l’utilisateur. Il semble logique en effet que ce dernier puisse ajouter des composants à son programme lorsqu’il souhaite affiner son analyse, par exemple après découverte d’un problème de performance, ou tout simplement afin de changer les visuali-sations qu’il utilise. La question qui se pose alors est de savoir comment traiter ces graphes changeant lors d’un déplacement dans le temps. La solution que nous avons choisie est de se rappeler la liste des composants présents lors de la sauve-garde d’un état. Seuls ces composants voient leur état restaurés, les autres étant soit réinitialisés afin de ne pas présenter d’état incohérent, soit détruits si l’utili-sateur le souhaite. Si un composant dont l’état a été enregistré n’existe plus au moment de la restauration, cet état est inutilisé. Il est ainsi possible de modifier le graphe d’analyse sans pour autant mettre en péril le mécanisme de déplacement dans le temps.

3.3.3 Interaction avec l’utilisateur

L’utilisateur dispose de deux outils pour contrôler le déplacement dans le temps, ces outils étant utilisables à partir du panneau de contrôle de session de

(a) Contrôle de la sauvegarde. (b) Contrôle des marques.

FIG. 3.3. – Les différents contrôles du déplacement dans le temps disponibles

permettent de régler le mécanisme de sauvegarde automatique de l’état de l’en-vironnement mais aussi d’associer des marques à des instants de l’exécution évaluée afin de pouvoir s’y ramener facilement.

Scope (figure 3.3).

Le premier a trait à la sauvegarde des états et lui permet de décider si et quand une sauvegarde automatique de l’état de l’environnement doit avoir lieu, l’autorise à forcer cette sauvegarde à un instant précis et lui permet de consulter la liste des instants où des sauvegardes ont eu lieu et de se déplacer à ces instants.

S’il est agréable de pouvoir être ramené rapidement aux instants de sauvegarde de l’état de l’environnement, une telle possibilité est assez primitive. Lorsqu’on visualise l’exécution d’une application parallèle on trouve des instants intéressants auxquels on souhaite pouvoir se rapporter ultérieurement. Ces instants ont très peu de chance de coïncider avec les instants de sauvegarde, et même s’ils sont peu nombreux il est souhaitable de pouvoir les retrouver rapidement.

Scope offre donc la possibilité de placer des marques dans l’exécution d’une application. Ces marques sont constituées d’un instant associé à un nom et à d’éventuels commentaires multimédia. L’utilisation d’un nom permet de classer facilement les marques et facilite leur gestion, alors que les commentaires auto-risent l’ajout d’informations telles que des notes, des questions en suspens ou tout document lié à l’instant marqué. Si l’on annote un instant en faisant référence à la marque associée à un autre instant, par exemple, on dispose d’un moyen efficace de navigation dans l’exécution, similaire dans son principe aux liens hypertextes dans un document classique. La gestion de ces marques est assurée par le second