Nous avons doté notre modèle par deux mécanismes. Le premier permet le retour en arrière c.à.d. il permet d‟annuler l‟adaptation et faire retourner l‟application à son état initial. Le deuxième est complément de ce premier mécanisme car il permet de vérifier la correction (correctness) de l‟application. S‟il y a certaines erreurs qui sont trouvées le mécanisme de retour en arrière va être déclenché. Les deux sous-sections suivantes présentent les principes d‟implémentations de ces deux mécanismes.
5.4.1 Le mécanisme de vérification de la correction de l’application
Ce mécanisme permet la vérification de la correction de l‟application d‟un point de vue syntaxique et sémantique. Il fonctionne comme un compilateur, mais il ne génère pas du code, c.à.d, il fait seulement une analyse lexicale, syntaxique et sémantique. Il permet donc, de détecter les erreurs syntaxiques et sémantiques, telles que le manque d‟une accolade ouvrante ou fermante, le manque de l‟implémentation d‟une fonction déclarée dans la balise , etc. Notons que cette vérification n‟est pas facile et il n y a pas une méthode définie ou un moyen spécial pour la faire.
Pour cela, nous avons proposé une méthode qui est simple, facile à mettre en oeuvre et très optimisée. Notre méthode de vérification est basée sur les deux mécanismes d‟instanciation des composants COM et de gestion des exceptions.
D‟après notre programmation avec les composants COM, nous avons remarqué que l‟exécution d‟une opération d‟instanciation d‟un composant via un appel à un constructeur prédéfini dans le langage de programmation utilisé (par exemple COM pour le langage PHP et ActiveXObject pour
JScript), conduit soit à la création d‟une instance soit à la génération d‟une exception si le composant contient une erreur syntaxique ou s‟il n‟est pas enregistré dans la base de registres.
Nous avons utilisé ce même principe pour l‟implémentation de notre mécanisme de vérification de la correction de l‟application, c.à.d, que nous avons utilisé le compilateur qui est intégré dans l‟hôte de script Windows (Windows Script Host) et qui permet l‟exécution des composant développés via la technologie Windows Script Component, ce qui a simplifié les choses et a rendu notre méthode simple, facile à mettre en oeuvre et optimisée.
Nous avons implémenté ce mécanisme dans le composant Implementation-ScriptCOM.WSC afin de facilité son utilisation, et nous l‟avons l‟implémenté sous forme d‟une fonction appelée test_correction().
La fonction test_correction(component) : cette fonction possède un seul paramètre qui représente une chaine de caractères indiquant le ProgID ou le CLSID du composant à vérifier. Elle contient deux bloc try{} et catch{} pour la gestion de l‟exception qui peut être levée par le constructeur ActiveXObject si le composant indiqué par le paramètre component contient une erreur syntaxique. S‟il y a une erreur, le bloc catche va être exécuté. Il permet de traiter l‟erreur trouvée.
Pour cela, il contient une seule instruction (return) permettant de terminer l‟exécution de la fonction par le renvoie d‟une chaine de caractères décrivant l‟exception levée. Dans le cas où le composant ne contient pas d‟erreurs, la fonction retourne une chaine de caractères vide. Voici le code de cette fonction :
Prog 5.1 Code source de la fonction test_correction().
Le block try{} permet la détection des exceptions. Pour cela, il contient deux appels au constructeur ActiveXObject. Le premier avec la chaine de caractère « Etat.wsc » comme identificateur et le deuxième avec le paramètre component comme identificateur. Notant qu‟on instancie le composant Etat.wsc en premier et on n‟est pas entrain de vérifier ce dernier.
Cette instruction d‟instanciation d‟un autre composant appartenant à l‟application avant l‟instanciation du composant qu‟on souhaite vérifier est très importante et représente l‟idée principale de notre mécanisme, car même si on fait l‟instanciation du composant et la gestion de l‟exception qui peut être levée par le constructeur ActiveXObject, l‟exception ne sera jamais levée. Ce résultat est expliqué par le fait que l‟instanciation est effectuée sur l‟ancienne version du composant, c.à.d que l‟instanciation est effectuer sur l‟implémentation du composant qui est déjà chargé dans la mémoire.
Pour résoudre ce problème, il faut instancier un autre composant appartenant à l‟application en premier et instancier par la suite, le composant que nous souhaitons vérifier, parce que dans ce cas là, la nouvelle version du composant sera chargée dans la mémoire et donc, si elle contient des erreurs, le constructeur lève une exception décrivant l‟erreur trouvée.
5.4.2 Le mécanisme de retour en arrière (Roll Back)
Ce mécanisme permet d‟annuler l‟adaptation et faire retourner l‟application à son état initial si l‟adaptation ne se termine pas correctement ou si des erreurs syntaxiques apparaissent dans le composant après son adaptation. Pour atteindre cet objectif, nous avons divisé l‟implémentation de ce mécanisme en deux parties.
Ce mécanisme est aussi implémenté dans l‟implémentation du notre modèle ScriptCOM. Ca implique que les deux parties sont intégrées dans le composant Implementation-ScripCOM.WSC.
Nous avons implémenté chaque partie sous forme d‟une méthode fournis par ce composant. Ces méthodes sont appelées respectivement securite() et RollBack() que nous allons décrire dans ce qui suit. La méthode securite(FILE) : L‟objectif de cette méthode est la sauvegarde du code du composant avant l‟exécution d‟une adaptation.
Pour cela, elle ouvre le fichier de code (indiqué par le paramètre FILE) du composant sujet à l‟adaptation, puis, elle récupère son contenu et l‟écrie dans un nouveau fichier possédant le même nom que le fichier de code du composant mais avec l‟extension .txt (fichier texte). Ce fichier reste existant jusqu’à la terminaison de l‟adaptation et la vérification de la correction de l‟application. Voici le code de cette fonction :
Prog 5.2 Code source de la fonction securit().
La méthode RollBack(FILE, f_code) : Elle possède deux paramètres appelées respectivement FILE et f_code. Le premier indique le chemin du fichier de code du composant sujet de l‟adaptation. Le deuxième indique le chemin du fichier qui contient l‟ancien code du composant c.à.d, le fichier qui contient le code du composant avant l‟exécution de l‟adaptation.
Cette méthode est exécutée dans le cas où le mécanisme de vérification de la correction de l‟application détecte une erreur. Lorsque cette méthode est appelée elle ouvre le fichier indiqué par le paramètre FILE en écriture, et ouvre aussi le fichier indiqué par le paramètre f_code en lecture, et par la suite, elle écrie le contenu de ce dernier dans le premier fichier ouvert (fichier du code), ce qui permet d‟annuler l‟adaptation et faire retourner l‟application à son état initial.
Voici le code de cette méthode :
Prog 5.3 Code source de la fonction RollBack().
A la fin, la méthode supprime le fichier crié par la méthode securite() avant l‟exécution de l‟adaptation.
Page suivante : 5.5 Application de gestion financière d’un magasin
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES