ORGANISATION GÉNÉRALE

NEXTSTEP offre également des outils de prototypage très puissants permet-tant par exemple de concevoir et tester une interface utilisateur sans avoir à pro-grammer. Les applications réalisées sous NEXTSTEP peuvent facilement être rendues modulaires et extensibles grâce aux mécanismes d’édition de liens dy-namiques utilisés en standard par l’environnement.

Il existe également un grand nombre de bibliothèques de classes d’interface de très haute qualité dans le domaine public. Leur disponibilité tend à réduire le temps de programmation et de mise au point et facilite l’interaction des applica-tions nouvellement écrites avec celles qui existent déjà.

Un autre point qui nous importait est que l’interface utilisateur de NEXTS-TEP est très précisément définie, et que les outils de développement supportent les règles de programmation d’interfaces en vigueur. Ceci garantit que le temps d’apprentissage de l’interface d’une nouvelle application par l’utilisateur est faible et que les applications fonctionnent bien ensemble.

Enfin NEXTSTEP fonctionne actuellement sur stations NeXT, machines com-patibles PC à base de processeurs Intel i386, systèmes Sparc (tels que ceux de Sun) et stations HP PA-RISC. Les spécifications de la partie interface utilisateur de NEXTSTEP ont été publiées sous le nom d’OpenStep. Les applications OpenS-tep fonctionnent sur tous les systèmes NEXTSTEP ainsi que sur Solaris, Windows NT et Windows 95 ; un portage sur X est également en cours et sera disponible gratuitement. Les applications NEXTSTEP et OpenStep sont portables et le parc de machines susceptibles de les faire fonctionner est déjà important et croît régu-lièrement.

1.2 Organisation générale

1.2.1 Découpage logique

Si nous essayons de découper un environnement de visualisation générique en parties nous pouvons distinguer d’une part une partie produisant les visualisations et d’autre part une partie permettant de contrôler l’environnement. La production des visualisations est le fruit de la transformation des données représentant une exécution : il faut d’abord obtenir ces données qui sont ensuite manipulées puis présentées sous une forme assimilable par l’utilisateur. Nous distinguons donc

non pas deux mais trois parties principales: la première correspond à l’acquisi-tion et à la producl’acquisi-tion des données correspondant à l’exécul’acquisi-tion de l’applical’acquisi-tion à évaluer, la deuxième englobe tout ce qui concerne l’évaluation, i.e. l’analyse et la visualisation d’indices de performances et la dernière permet de contrôler l’envi-ronnement et la session d’évaluation de performances (choix de la trace, des outils d’évaluation, déplacement dans l’exécution de l’application, etc.).

Dans le cas d’une visualisation dirigée par les traces la première partie consiste à extraire les événements de la trace décrivant l’exécution d’une application et à se servir de ces événements pour reconstituer les états successifs de l’application : c’est le rôle de la lecture de traces et de la simulation qui sont décrites au chapitre 2 page 87. Cette partie est dépendante du modèle de programmation utilisé et de la syntaxe des traces ce qui signifie qu’il faut des outils spécifiques à chaque format de traces et à chaque modèle de programmation.

En revanche la seconde partie a un caractère générique : un calcul de moyenne n’a pas besoin de connaître la signification des données sur lesquelles il calcule ; un histogramme ou une courbe peuvent être utilisés indifféremment pour repré-senter des tailles de messages ou des pourcentages d’utilisation des ressources de calcul ; une représentation de graphe peut aussi bien montrer la topologie d’une application qu’un graphe d’appel de procédures à distances ; etc. Afin qu’ils soient réutilisables les outils ne connaissent absolument pas la sémantique des données qu’ils manipulent : c’est l’utilisateur qui donne une sémantique en choisissant quelles données sont fournies à quels outils.

Quant à la dernière partie elle fournit l’interface entre l’utilisateur et l’envi-ronnement en lui donnant les outils nécessaires à la conduite d’une session d’éva-luation de performances. Cette interface permet non seulement d’effectuer des actions telles que le choix d’une trace et des outils qui seront utilisés pour son analyse mais aussi de contrôler l’action de ces outils ainsi que la façon dont la trace est déroulée durant l’évaluation de performance. Elle fournit également un cadre dans lequel les différents outils disponibles peuvent s’intégrer pour présen-ter une inprésen-terface de manipulation cohérente à l’utilisateur. Enfin elle se charge de présenter une interface générique permettant de manipuler les outils de la partie spécifique afin que l’utilisateur n’ait pas à changer sa manière d’utiliser l’environ-nement lorsque ces outils changent.

On comprend alors quel est l’intérêt de ce découpage logique en trois parties (figure 1.1 page 64) : il permet d’isoler soigneusement les outils qui devront être

1.2. ORGANISATION GÉNÉRALE

réécrits pour chaque modèle de programmation et encourage l’environnement à se doter de moyens de cacher leur spécificité à l’utilisateur. Mais il garantit aussi que les outils d’analyse de données et de visualisation réalisés seront réellement génériques puisqu’ils n’auront pas un accès direct à la trace, un tel accès risquant d’induire une dépendance de ces outils par rapport aux formats de traces ou d’évé-nements exploités pour l’évaluation de performance.

1.2.2 Principes directeurs

Nous distinguons trois niveaux de facilité d’extension à fournir aux utilisateurs de Scope. Le plus simple permet à l’utilisateur d’ajouter le calcul de nouveaux indices de performances ou de changer les données visualisées ou les données elles-mêmes ; ce niveau ne doit pas requérir de connaissance du fonctionnement des parties de l’environnement ni du langage d’implantation de l’environnement. Le plus complexe autorise l’ajout de nouveaux objets complexes dans l’environ-nement (un lecteur de traces, un simulateur, une visualisation, etc.), ces objets pouvant avoir une interaction complexe avec l’environnement ; une telle modifi-cation requiert la compréhension des mécanismes internes de l’environnement et de la programmation. Enfin le niveau intermédiaire autorise l’ajout de nouveaux objets simples dans l’environnement (analyse de données, statistiques, filtrage, etc.) ; il nécessite la programmation de ces objets et celle-ci doit être simplifiée au maximum.

Pour permettre l’extension facile de l’environnement par les utilisateurs sans leur demander une grande expertise en programmation nous avons doté Scope d’un langage de programmation visuelle, Eve (pourEnvironnement visuel ex-tensible), qui permet de construire graphiquement des programmes sous forme d’un graphe de composants de manipulation de donnés.

Ce langage, que nous décrivons au § 1.3 page 65, est la base de Scope : l’en-vironnement est formé par un ensemble d’objets ou composants qui transforment des données et se les transmettent. Ces composants sont incorporés dynamique-ment dans l’environnedynamique-ment en fonction des besoins et des choix de l’utilisateur, offrant ainsi une très grande souplesse puisque l’ensemble de l’environnement peut être à tout instant modifié selon la volonté de l’utilisateur. Cette modifica-tion de l’environnement correspond au niveau d’extension simple. Les autres ni-veaux d’extension demandent simplement l’écriture de composants Eve, certains

Contrôle de l’environnement et des sessions (lecture de traces, Partie spécifique simulation) (analyse de données, statistiques, visualisation) Partie générique Scope

FIG. 1.1. – Les différentes parties qui composent Scope sont interconnectées

mais c’est le contrôle de l’environnement et des sessions qui contrôle l’interac-tion principale avec l’utilisateur.

étant simplement plus complexes que d’autres puisqu’ils doivent obéir à plus de contraintes (par exemple s’intégrer avec le contrôle de session de Scope pour les lecteurs de traces).

Cette architecture a de nombreux intérêts. Les différents outils de l’environ-nement étant isolés sous forme de composants Eve il est facile de prototyper un nouvel outil sans influencer le comportement ou la stabilité d’outils déjà dispo-nibles. L’intégration dynamique de composants dans l’environnement signifie que l’utilisateur peut ajouter de nouveaux outils pour l’aider au moment où il le sou-haite, i.e. après avoir découvert un problème de performance par exemple. Cela veut donc dire que l’environnement n’utilise de la mémoire et du temps machine que pour ce qui est réellement nécessaire : il est susceptible d’être non seulement plus rapide que si tous les outils étaient toujours disponibles mais aussi capable de traiter de plus grandes traces. Cela signifie également qu’il n’est pas néces-saire de modifier l’environnement lui-même pour l’étendre : il suffit d’écrire un nouveau composant et de l’y incorporer. Outre le fait d’isoler le composant cette capacité permet un échange facile des extensions de l’environnement au sein d’un groupe d’utilisateurs. Enfin le fait de se servir d’un langage de programmation visuelle fournit une interface de développement d’outils bien spécifiée et permet de faire bénéficier tous les composants développés des améliorations apportées au langage. Par exemple si celui-ci comporte la possibilité d’exécuter un