Ne pas imprimer cette page,  celle-ci pouvant être mise à jour par la suite. Le numéro de version figure en dessous du titre.

Objectif du TP

Construire des outils permettant d'analyser les structures de bundles en java. 

A propos de bundle

Dans ce TP on appelle "paquet" ou "bundle" toute source de données permettant à la JVM de charger des classes. Cette notion est souvent très mal formalisée.  C' est pourtant un élément important de l'environnement Java et permet une grande souplesse dans un contexte industriel de développement dans la mesure ou la notion de bundle permet de contrôler la provenance des classes formant une application. D'un point de vue concret c'est la notion de classpath qui est connue (typiquement la valeur du "classpath" est définie via la variable d'environment "CLASSPATH" ou via l'option de commande '-classpath' ou '-cp'). Un classpath est une séquence (de références vers) des bundles. Un bundle est avant tout une unité de déploiement. Dans le contexte de ce TP on prendre en compte 3 types de bundles :

• les répertoires contenant des classes (typiquement les répertoires nommés "classes")
• les archives ".zip"
• les archives ".jar"

Le tableau ci-dessous montre une séquence (factice) de 4 bundles correspondant typiquement au classpath suivant sous windows :

	PRI\VIEWER\classes\;LIB\wDebug2-0.jar;PRI\LIB\wExtension1-3.zip;LIB\w2-0.jar

Il est souvent difficile à la lecture d'un classpath de savoir quels sont (1) les classes qui seront effectivement prises en compte lors de l'exécution,  et (2) les paquetages mis effectivement à contribution. De même il peut être difficile de savoir si un bundle est nécessaire ou si sa position dans la séquence de bundle est importante ou non. L'objectif de ce TP vise à construire une librairie permettant de représenter les séquences de bundles, puis à construire des outils permettant l'exploration de tels séquences.

PRI\VIEWER\classes\

LIB\wDebug2-0.jar

PRI\LIB\wExtension1-3.zip

LIB\w2-0.jar

  fr

  com/coyot/Helper.class

   fr\imag\graph\Graph.class

  com/coyot/Helper.class

    imag

  com/coyot/Warning.class

   fr\imag\graph\readme.txt

  com/coyot/Warning.class

       app

  com/coyot/debug/Trace.class

   fr\imag\graph\Node.class

  com/acme/graph/Window$1.class

          Viewer.class

  com/coyot/debug/Console.class

   com\acme\graph\Node.class

  com/acme/graph/Graph.class

          Editor.class

   com\acme\graph\NodeItem.class

  com/help/index.html

          Editor$1.class

  com/acme/graph/Window$Map$1.class

       lib

  com/acme/graph/Window$Map.class

       gui

  com/help/preview.html

          TextGui.class

  com/help

          AWTGui.class

  com/help/overview.html

          SwingGui.class

  com/acme/graph/Node.class

          help.html

  com/acme/graph/Edge.class

          images

  com/acme/view/GraphRenderer.class

             helpIcon.gif

  com/acme/view/NodeRenderer.class

             close.Icon.gif

  com/acme/view/EdgeRenderer.class

  com

  com/acme/graph/Window.class

    acme

       view

          NodeColor.class

          NodeRenderer.class

Télécharger la dernière version de BUNDLEVIEWER se trouvant dans le répertoire ARCHIVES et décompresser cette archive dans le répertoire de votre choix.

(Q1) Constitution d'un jeu de test

Pour bien comprendre la signification des séquences de bundles, la première étape consiste à définir un jeu de test d'un programme décrit en Q4 qui pour la séquence de bundles

	PRI\VIEWER\classes\;LIB\wDebug2-0.jar;PRI\LIB\wExtension1-3.zip;LIB\w2-0.jar

produit ce texte qui, pour chaque paquetage contenu dans les bundles, indique dans quel(s) bundle(s) se trouve chaque classe. Ce texte n'est qu'une représentation externe de ce que le programme qu'il s'agit de construire permet de représenter.

• (a) compléter ce texte qui se trouve dans le fichier tests\data\1\bundleMap.txt . On notera que les bundles sont ordonnés selon la séquence d'origine, que les paquetages sont classés par ordre alphabétique et que les classes sont classées par ordre alphabétique selon leur nom court. Une attention particulière devra être portée aux nombres d'espaces, afin que les résultats puissent être testés systématiquement.
• (b) créer dans le répertoire tests\data\1 les répertoires et bundles représentant l'exemple fourni dans le tableau ci-dessus. Dans un premier temps le contenu des fichiers n'a pas d'importance. Il suffit donc de créer les hiérarchies de fichiers et les archives zip et jar correspondant à l'exemple.
• (c) créer d'autres jeux de tests au fur et à mesure des besoins dans les questions suivantes.

(Q2) Implémentation du paquetage d'analyse

Le paquetage fr.imag.reflect.bundle est décrit par les spécifications fournies en UML. Créer des jeux de tests  pour la classe Naming et implémenter cette classe.

(Q3) Définition du processus de production

L'objectif est d'automatiser le processus de production des différents élements logiciels en utilisant l'outil Ant.  Pour cela il est nécessaire de définir une structure systématique des différents fichiers formant le logiciel. La structure peut être observée dans ce répertoire.Dans le répertoire bin la commande setvar permet de positionner les variables en fonction de l'environnement utilisé. Ant doit être installé, ainsi que JUnit. Dans le repertoire principal se trouve une version initiale du fichier build.xml. Compléter le fichier readme.txt se trouvant dans le fichier principal en fournissant les éléments nécessaires au développeur pour qu'il sache comment compiler, tester, exécuter etc. Il s'agit donc d'écrire la documentation du processus de production.

(Q4) Production du logiciel

Les pécifications fournies en UML définissent dans le paquetage ConformityLevels différents niveau de conformités. Pour chaque niveau, produire d'abord des tests puis fournir une implémentation correspondante.