HTML Test Page

Fonctionnement de l'Applet

Retour

	Description des classes.
	Résumé du fonctionnement de l'Applet.
	Notes ( Améliorations possibles).
	Problèmes recontrés.

L'Applet est composée de 5 classes.

Dictionnaire.

Compresse.

Texte Entree et Texte LZW.

LZW_Interface.

La classe dictionnaire:

Elle remplit la liste qui sert de dictionnaire. Les valeur vont de 32 a 255 en code ASCII. C'est aussi elle qui vérifie si les séquence se trouvent dans le dictionnaire par l’intermédiaire des méthodes Add_Dico_Contenu() et Cherche_Valeur_Dico. La liste n'est la que pour présenter les données. C'est une table de hachage qui gère les séquences. Le fait de prendre une table de hachage facilite les manipulations de recherche et d'ajout dans le dictionnaire. Pour pouvoir améliorer la gestion des clés, la méthode Get_La_Derniere_Clef() a été implémentée pour pouvoir toujours récupérer la dernière clé qui a été fabriquée. Scan_Dico() est la méthode qui va vérifier si une clé est bien présente dans le dictionnaire. Quant a Select_Index() est est la juste pour sélectionner le dernier élément de la liste. Ceci offre une meilleur visualisation de l’évolution du dictionnaire.

La classe Compresse:

C'est le cœur de la compression. Les deux algorithmes de compression et de décompression y sont implémentes. Les méthodes Start_Compresse et Start_Décompresse ont été rajoutées pour initialiser les variables ainsi que les objets. Pour des raisons de visibilité et pour voir le fonctionnement de l'Applet une méthode run() a été mise en place pour ralentir l'Applet et voir l’évolution des séquences. Cette méthode run() est un Thread qui inclus les deux algorithmes de compression et de décompression.

Naturellement cette classe est une extension de la classe Dictionnaire et hérite des fonctionnalités de la classe Dictionnaire. Le dictionnaire est instancié en protected dans la classe Compresse.

Les classs Texte_Entree et Texte_LZW:

Ces deux classes ne son ni plus ni moins que des objets standards améliorés. C'est à dire que Texte_Entree est un JTexteField auquel j'ai rajouté un label. C'est plus simple de faire comme ceci car il y a 6 objets de ce type dans l'Applet. De plus, c'est plus élégant d'exploiter la technologie objets. On aurait très bien tout mettre dans une seule classe et la lisibilité de l'Applet aurait été moins claire. Le seul inconvénient est qu'il faut définir de nouveau des méthodes standards comme par exemple la méthode Change_Le_Contenu() qui n'est qu'une méthode standard setText() de l'objet JTexteField. La classe Texte_LZW est du même tonneau sauf que c'est l'objet JList qui est amélioré avec des méthodes comme par exemple la visualisation des états de la lecture du dictionnaire. (Voir la rubrique Notes)

La classe LZW_Interface:

Cette classe est tout simplement l'Applet. On y construit touts les objets nécessaires au bon fonctionnement de l'Applet. Certaines classes sont déclarées static car il n'y a pas d'instance proprement dite de l'Applet. Comme la classe LZW_Interface est l'interface qui va servir pour faire dialoguer les objets entres eux, on devra faire référence a la classe elle même et non aux instances crées. En fait, LZW_Interface:fait aussi office de dispatcher de messages entre les différents objets.

Exemple :

Dans la classe compression se trouve la ligne de code suivante:

LZW_Interface.U.Change_Le_Contenu(Union);

La classe LZW_Interface a les instructions pour instancier la classe compresse et par conséquent un objet Compression. Elle peut aussi instancier la classe Texte_Entree en en faire un objet appelé U. Mais il n'y a pas d'instance de LZW_Interface.

	Maintenant si je veux modifier l'objet U par l'intermediaire de l'objet Compression il faut envoyer le message a l'Objet LZW_Interface qui lui, va activer la méthode de l'objet Change_Le_Contenu(Union) de l'objet U.
	Message envoyé par l'intermediaire de l'objet LWZ_Interface

En résumé: L'Applet fonctionne de la manière suivante.

   Lire le texte caractère par caractère.

   Stocker les séquences dans un vecteur.

   Compresser les séquences.

   Mettre à jour le dictionnaire ainsi que les champs donnant des informations sur les séquences.

   Le dictionnaire est une HashTable ou est stockée la clé ainsi que la valeur.

   Copier le vecteur dans un tableau.(Ce qui permet d'avoir un tableau dynamique)

   Lire le contenu du tableau

   Décompresser les séquences qui sont dans le tableau.

   Mettre à jour le dictionnaire ainsi que les champs donnant des informations sur les séquences.

En ce qui concerne l'algorithme il est peut être possible d'optimiser le code, mais au détriment de la lisibilité.

Pour avoir une vue plus globale des classes et de leur interaction un schéma à la norme UML serait peut être plus utile. Quoi que pour 5 classes et pas trop de méthodes?

Notes:

Suite à la suggestion de monsieur Loewenguth. En ce qui concerne la décompression des séquences à partir d'une séquence déjà compressée, je pense qu'une Applet n'est pas faite pour cela. il faudrait utiliser une application qui puisse donner l'accès à un fichier texte. De plus il faut que le texte compressé soit compatible avec un système de décompression qui permet de se renseigner sur la longueur des séquences. Par exemple mettre en tête du fichier lors de la compression les indices ou les séquences qui changent de longueur. Ex : de 0 à 400 je suis sur 7 bits et de 401 à 450 sur 8 bits. Lorsque les séquences seront lues, il faut incrémenter un compteur, tester ou on se trouve et extraire le nombre de bits correspondants. Le tout à partir d'un fichier binaire naturellement.

L'utilisation de la classe StringBuffer plutot que la concatenation des String avec l'opérateur +, serait une manière plus élégante de manipuler les chaînes de caractères.

Une amélioration de l'interface est peut être possible, mais je pense qu'elle est assez claire et en plus elle est en Swing.

Cette Applet a été faite avec JBUILDER 4 de Borland. J'espère qu'il est encore disponible sur le site de www.borland.com, car il est possible d'avoir la version Foundation qui n'est pas limité dans le temps, mais offre des fonctionnalités réduites amplement suffisantes pour faire des programmes intéressants. En effet seuls les Java Beans Borland ne sont pas disponibles, mais tout le JDK 1.3 est opérationnel. En plus il est multi JDK et c'est du pure Java.

Forte de Sun est aussi pas mal, mais dans les deux cas 128 Mo re RAM minimum sont indispensables pour travailler correctement.

Pour la gestion des couleurs, les séquences vertes sur fond noir indiquent que la séquence est déjà dans le dictionnaire et les séquences non présentes dans le dictionnaire sont en rouge sur fond blanc. Toutefois il faut remarquer que lors de la déompression d'une séquence normale tout est considéré comme étant dans le dictionnaire. Mais avec une séquence comme TOTOTOT ou 1111111111111111 ce n'est plus le cas.( Le mieux est d'essayer et voir pourquoi avec l'Applet.) S'il y a un doute, je donne une réponse. Dans une chaine qui contient beaucoup d'occurences comme TOTOTOTOT qui ne contient que des T et O, l'algorithme génère une séquence du type 84 76 256 258 257. Et oui !! 256 258 et 257 ne sont pas dans l'ordre. Quand on décompresse l'adresse 258 n'est pas générée. ( Probleme de l'algorithme du cours )

Problèmes rencontrés :

Le pricipale problème est que j'ai utilisé un Flow Layout avec des Panels(Panneaux). C'est bien, mais dès que l'on imbrique les panneaux les un dans les autres, bonjours les dégats. Des containaires qui s'affichaient avant ne s'affichent plus ou changent de place, bref il vaut mieux éviter d'imbriquer plus de 3 panneaux. Un Layout Null est préférable. J'ai aussi voulu rajouter un peut de graphisme avec Java 2D, grâce au Layout et c'est totalement ingérable.

La cration du Thread est essentiel pour ralentir L'Applet, mais in perd en lisibilité.

Ecire une Applet en Java 1.3 et Swing implique des problèmes de compatibilités entre Browser. Toutefois avec IE5.5 et Plug In 1.3_0_02 ou Netscape 6 pas de problèmes. Sauf que, il vaut mieux avoir le petit utilitaire que l'on trouve chez SUN pour faire du code HTML compréhensible par les browsers. cet utilitaire s'appelle HTML Converter.

Des difficultés sont apparues avec l'algorithme de décompression du cours. Décompresser COCOROCO , CORI fonctionne correctement, mais une séquence comme TOTOTOT ne fonctionne pas.

Retour

Fait par Schild Patrick le 15/06/2001

schild.patrick@wanadoo.fr

	Dictionnaire.
	Compresse.
	Texte Entree et Texte LZW.
	LZW_Interface.

	En ce qui concerne l'algorithme il est peut être possible d'optimiser le code, mais au détriment de la lisibilité.
	Pour avoir une vue plus globale des classes et de leur interaction un schéma à la norme UML serait peut être plus utile. Quoi que pour 5 classes et pas trop de méthodes?

	Suite à la suggestion de monsieur Loewenguth. En ce qui concerne la décompression des séquences à partir d'une séquence déjà compressée, je pense qu'une Applet n'est pas faite pour cela. il faudrait utiliser une application qui puisse donner l'accès à un fichier texte. De plus il faut que le texte compressé soit compatible avec un système de décompression qui permet de se renseigner sur la longueur des séquences. Par exemple mettre en tête du fichier lors de la compression les indices ou les séquences qui changent de longueur. Ex : de 0 à 400 je suis sur 7 bits et de 401 à 450 sur 8 bits. Lorsque les séquences seront lues, il faut incrémenter un compteur, tester ou on se trouve et extraire le nombre de bits correspondants. Le tout à partir d'un fichier binaire naturellement.
	L'utilisation de la classe StringBuffer plutot que la concatenation des String avec l'opérateur +, serait une manière plus élégante de manipuler les chaînes de caractères.
	Une amélioration de l'interface est peut être possible, mais je pense qu'elle est assez claire et en plus elle est en Swing.
	Cette Applet a été faite avec JBUILDER 4 de Borland. J'espère qu'il est encore disponible sur le site de www.borland.com, car il est possible d'avoir la version Foundation qui n'est pas limité dans le temps, mais offre des fonctionnalités réduites amplement suffisantes pour faire des programmes intéressants. En effet seuls les Java Beans Borland ne sont pas disponibles, mais tout le JDK 1.3 est opérationnel. En plus il est multi JDK et c'est du pure Java.
	Forte de Sun est aussi pas mal, mais dans les deux cas 128 Mo re RAM minimum sont indispensables pour travailler correctement.
	Pour la gestion des couleurs, les séquences vertes sur fond noir indiquent que la séquence est déjà dans le dictionnaire et les séquences non présentes dans le dictionnaire sont en rouge sur fond blanc. Toutefois il faut remarquer que lors de la déompression d'une séquence normale tout est considéré comme étant dans le dictionnaire. Mais avec une séquence comme TOTOTOT ou 1111111111111111 ce n'est plus le cas.( Le mieux est d'essayer et voir pourquoi avec l'Applet.) S'il y a un doute, je donne une réponse. Dans une chaine qui contient beaucoup d'occurences comme TOTOTOTOT qui ne contient que des T et O, l'algorithme génère une séquence du type 84 76 256 258 257. Et oui !! 256 258 et 257 ne sont pas dans l'ordre. Quand on décompresse l'adresse 258 n'est pas générée. ( Probleme de l'algorithme du cours )

	Le pricipale problème est que j'ai utilisé un Flow Layout avec des Panels(Panneaux). C'est bien, mais dès que l'on imbrique les panneaux les un dans les autres, bonjours les dégats. Des containaires qui s'affichaient avant ne s'affichent plus ou changent de place, bref il vaut mieux éviter d'imbriquer plus de 3 panneaux. Un Layout Null est préférable. J'ai aussi voulu rajouter un peut de graphisme avec Java 2D, grâce au Layout et c'est totalement ingérable.
	La cration du Thread est essentiel pour ralentir L'Applet, mais in perd en lisibilité.
	Ecire une Applet en Java 1.3 et Swing implique des problèmes de compatibilités entre Browser. Toutefois avec IE5.5 et Plug In 1.3_0_02 ou Netscape 6 pas de problèmes. Sauf que, il vaut mieux avoir le petit utilitaire que l'on trouve chez SUN pour faire du code HTML compréhensible par les browsers. cet utilitaire s'appelle HTML Converter.
	Des difficultés sont apparues avec l'algorithme de décompression du cours. Décompresser COCOROCO , CORI fonctionne correctement, mais une séquence comme TOTOTOT ne fonctionne pas.