5.5 Application de gestion financière d’un magasin

5.5.1 Description de l’application

Aujourd‟hui, dans notre monde de travail, chaque organisation génère un volume très important d‟information. C‟est pour cela que l‟entreprise ou l‟organisation est obligée d‟utiliser des outils informatiques pour faciliter son travail, c.à.d, que l‟organisation est obligée d‟automatiser son système par le développement de ce que nous appelons un Système d’information.

Dans ce même cadre, et en utilisant notre modèle ScriptCOM, nous avons conçu une application de gestion financière d‟un magasin qui fait la vente et la maintenance du matériels informatiques. Nous avons aussi développé cette application afin de concrétiser les concepts que nous avons proposés dans ce modèle et de les valider à travers cet exemple d‟application qui permet de faire : Une gestion des factures : elle permet l‟ajout, la modification et la suppression d‟une facture.

En plus, elle offre la possibilité d‟effectuer des recherches sur une facture par numéro, par date, par fournisseur, ainsi que la possibilité de rechercher les factures payées et celles non payées. Une gestion des BLs (Bons de Livraison) : elle permet la mise à jour d‟un BL (ajout, modification et suppression). En plus, elle propose la possibilité d‟effectuer des recherches sur un BL par numéro, par date, par fournisseur avec aussi la possibilité de rechercher les BLs payées et ceux non payées.

Une gestion des Fournisseurs: L‟application permet la mise à jour d‟un fournisseur (ajout, modification et suppression). En plus, elle permet d‟afficher la liste des fournisseurs avec la possibilité d‟effectuer des recherches sur un fournisseur par numéro. Aussi, elle permet de rechercher les factures payées et celles non payées et les BLs payés et ceux non payés d‟un fournisseur donné. Une gestion des recettes : L‟application permet l‟ajout, la modification et la suppression d‟une recette.

Elle offre en plus la possibilité d‟afficher toutes les recettes enregistrées dans la base de données et d‟effectuer une recherche sur une recette par date. Une gestion des dépenses : L‟application permet l‟ajout, la modification et la suppression d‟une dépense. Elle permet aussi d‟effectuer des recherches sur une dépense par numéro et par date.

Des statistiques : Cette application permet de faire des statistiques concernant l‟état du magasin. Elle affiche le total des bénéfices et des dépenses, en plus de la somme de toutes les recettes, et indique à la fin l‟état du magasin. Elle permet de plus, de faire des statistiques concernant l‟état des ventes. Elle affiche la date de la première recette et celle de la dernière recette, la moyenne, la variance, la valeur minimale et la valeur maximale des recettes enregistrées dans la base de données.

5.5.2 Conception de l’application

D‟après la description de l‟application que nous avons présentée dans la section précédente, celle-ci doit effectuer une bonne manipulation des factures, des Bons de livraison, des recettes, des fournisseurs, des employés et des dépenses. Afin d‟atteindre cet objectif et faire une bonne gestion financière du magasin nous avons proposé les règles de gestion suivantes :

 Chaque facture peut être payée à travers plusieurs tranches

 Chaque facture possède un bénéfice.

 Un fournisseur peut être payé par chèque ou par argent liquide.

 Un fournisseur doit avoir au moins une facture.

 Un fournisseur peut ne pas posséder des bons de livraison.

 Chaque bon de livraison peut être payé à travers plusieurs tranches.

 Chaque bon de livraison possède un bénéfice.

 Un employé peut prendre des acomptes tant que la somme de la valeur qu‟il demande ainsi que la valeur des acomptes qu‟il a prit ne dépasse pas le nombre de ses jours de travail dans le mois courant fois son salaire d‟une journée.

Pour rependre à cette spécification nous avons élaboré le diagramme de classe suivant :

Figure 5.8 Le diagramme de clases de l’application.

Pour la gestion des factures, nous avons élaboré la classe Facture, et pour la gestion des BLs nous avons élaboré aussi une seule classe appelée BL. De plus, nous avons élaboré la classe Depense pour la gestion des dépenses et la classe Recette pour la gestion des recettes. Aussi, pour la gestion des employés, nous avons élaboré trois classes appelées respectivement Employé, Acompte et Absence.

Comme les deux classes Facture et BL contiennent des attributs communs, nous avons met ces attributs dans une classe appelée C_Facture_BL qui va être héritée par ces deux classes. Aussi, comme chaque fournisseur doit avoir au moins une facture et automatiquement au moins un payement, et qu‟il peut avoir des BLs et si c‟est le cas, il doit avoir des payements de ces BLs, nous avons met des relations d‟agrégation entre la classe Fournisseur et les deux classes Facture et BL. Nous avons aussi met des relations d‟association entre la classes Employé et les deux classes Acompte et Absence. Afin de mettre ce diagramme de classe en application, nous l‟avons transformé en un Schéma Relationnel présenté par la figure suivante 5.2.

Figure 5.9 Le schéma relationnel de l’application.

Facture (Num_fact, Num_four, mont_vent, benifice, date_fcat) : cette relation regroupe certaines informations sur une facture. Le numéro de la facture (Num_fact) est la clé de cette relation. Les autres champs de cette table représentent respectivement le numéro du fournisseur, le montant de la facture, ses bénéfices et sa date de facturation.

Payement-Fact (Num_Pay, Num_fact, somme, date_Pay) : cette relation regroupe certaines informations sur le payement d‟une facture. Le numéro du payement (Num_Pay) est la clé de cette table alors que Le numéro de la facture (Num_fact) est une clé étrangère dans cette relation. Les autres champs représentent respectivement la somme payé et la date du payement.

BL (Num_bl, Num_four, mont_vent, benifice, date_bl) : cette relation regroupe certaines informations sur un bon de livraison. Le numéro du bon (Num_bl) est la clé de cette relation. Les autres champs de cette table représentent respectivement le numéro du fournisseur, le montant du BL, ses bénéfices et sa date.

Payement-BL (Num_Pay, Num_bl, somme, date_Pay) : cette relation regroupe certaines informations sur le payement d‟un bon de livraison. Le numéro du payement est la clé de cette table alors que Le numéro du BL (Num_bl) est une clé étrangère dans cette relation. Les autres champs représentent respectivement la somme payé et la date du payement.

Depense (Num_Dep, cause, montant, date_Dep) : cette relation regroupe certaines informations sur une dépense. Le numéro de la dépense (Num_Dep) est la clé de cette relation. Les autres champs de cette table représentent respectivement la cause de la dépense, son montant et sa date.

Recette (Num_recette, Valeur, date_rect) : cette relation regroupe certaines informations sur une recette. Le numéro de la recette (Num_rect) est la clé de cette relation. Les autres champs de cette table représentent respectivement la valeur de la recette et sa date.

Fournisseur (Num_four, Nom, Prenom, Adr, Type_pay) : cette relation regroupe certaines informations sur un fournisseur. Le numéro du fournisseur (Num_four) est la clé de cette relation. Les autres champs de cette table représentent respectivement le nom et le prénom du fournisseur, son adresse et son type de payement.

Employé (Num_EMP, Nom, Prenom, Adr, Tel, salaire, fct, date_EMB) : cette relation regroupe certaines informations sur un employé. Le numéro de l‟employé (Num_EMP) est la clé de cette relation. Les autres champs de cette table représentent respectivement le nom et le prénom de l‟employé, son adresse, son numéro de téléphone, son salaire, sa fonction et sa date d‟embauche.

Acompte (Num_Act, Num_EMP, Valeur, date_Act, description) : cette relation regroupe certaines informations sur un acompte. Le numéro de l‟acompte (Num_Act) est la clé de cette relation. Les autres champs de cette table représentent respectivement le numéro de l‟employé, la valeur de l‟acompte, et sa date.

Absence (Num_abs, Num_EMP, date_abs) : cette relation regroupe certaines informations sur l‟absence d‟un employé. Le numéro de l‟absence (Num_abs) est la clé de cette relation. Les autres champs de cette table représentent respectivement le numéro de l‟employé, la date de son absence.

5.5.3 Description de l’implémentation de l’application

Nous avons utilisé notre propre modèle ScriptCOM pour développer cette application. L‟interface de celle-ci représente la partie client qui demande et utilise les services d‟un ensemble de serveurs qui sont des composant ScriptCOM de traitement.

Dans cette application nous avons utilisé aussi des composants COM existant dans le système d‟exploitation Windows. Ces composants sont :

 Le composant “Scripting.FileSystemObject”: qui permet la manipulation des fichiers et des répertoires (lecture, écriture, parcours,…etc.).

 Le composant “ADODB.Connection”: qui permet l‟établissement d‟une connexion à la base de données.

 Le composant “ADODB.Recordset”: qui permet l‟exécution des requêtes et le parcours des résultats.

Notons que nous faisons ici une réutilisation des composants développés par des programmeurs et avec des langages que ne connaisse pas. Donc, cette application est développée complètement à base de composants.

Nous avons utilisé le langage HTML (hyper text markup language) et la bibliothèque AJAX pour le développement de l‟interface home/machine de l‟application. Nous avons aussi, utilisé le langage PHP pour le développement de la partie client (partie dynamique) qui consiste à invoquer les fonctions fournies par les composants et d‟afficher les résultats de leurs exécutions.

Nous avons choisi le langage PHP car il possède un constructeur prédéfini appelée COM, permettant la création d‟une instance d‟un composant COM. De plus, c‟est un langage open source. Pour le système de gestion de base de données SGBD, nous avons utilisé MYSQL qui est l‟un des SGBDs les plus puissant et les plus utilisé aujourd‟hui (gestion des trigeurs, une meilleur gestion des transactions, etc.).

Notre application est constituée donc, d‟un ensemble de scripts PHP qui représente les clients plus un ensemble de composants COM et ScriptCOM qui représente les serveurs. L‟application contient un composant essentiel, appelé implementation-ScriptCOM.WSC que nous avons présenté dans la section 5.3.

Elle contient aussi un autre composant appelé Connexion.WSC très important et très utilisé par tous les autres composants parce qu‟il permet d‟établir une connexion à la base de données.

L‟application contient aussi un composant Facture.WSC pour la gestion des factures, un composant BL.WSC pour la gestion des BLs, un composant Recette.WSC pour la gestion des recettes, un composant Fournisseur.WSC pour la gestion des fournisseurs, un composant Etat.WSC pour faire des statistiques concernant l‟état du magasin et l‟état des ventes, et un dernier composant appelé Adaptateur.WSC qui est chargé de s‟adapter automatiquement et d‟adapter certain composants dans l‟application.

Nous avons séparé la politique de l‟adaptation dans l‟application afin de réduire la complexité de la modification de celle-ci, et aussi pour faciliter l‟ajout d‟autre politique sans toucher le code fonctionnel des composants adaptés. Donc, dans l‟application, il y a une séparation des préoccupations à cause de l‟utilisation des composants et il y a une séparation de l‟adaptation à cause de la technique que nous avons adoptée pour la programmation. Dans les sous-sections suivantes, nous allons décrire en détail l‟implémentation de chaque composant ScriptCOM que nous avons développé dans l‟application.

5.5.3.1 Le composant Connexion.WSC

Ce composant fourni une seule interface plus les trois autres des contrôleurs. Celle-ci possède une seule fonction appelée connexion. Comme le langage JScript que nous avons utilisé pour le développement de nos composants ScriptCOM n‟a aucun support pour la manipulation des bases de données, on a été obligé d‟utiliser les deux composants “ADODB.Connection” et “ADODB.Recordset” qui existent dans le système d‟exploitation Windows. Pour établir une connexion à une base de données et exécuter une requête en utilisant ces deux composants, il faux instancier ces deux composants.

Par la suite, il faut appeler la fonction Open() de chaque instance pour ouvrir une connexion et exécuter une requête, en utilisant la connexion établie.

Pour l‟ouverture d‟une connexion, il faut connaître le nom de la base de données et son pilote, le nom d‟utilisateur et le mot de passe. Toutes ces informations doivent être transmises à la fonction Open() du composant “ADODB.Connection” sous la forme d‟une chaine de caractères représentée suivant un format donné. La valeur de retour de la fonction connexion du composant Connexion.WSC est cette chaine de caractères. Par la suite, tous les autres composants qui invoquent cette fonction utilisent cette chaine pour établir une connexion à la BDD.

La fonction connexion extrait les informations qui concernent le nom de la base, le nom d‟utilisateur, etc. à partir d‟un fichier info.txt qui existe normalement dans le répertoire qui contient l‟application, ou à partir d‟autre copies existant dans des répertoires différents si ce fichier est endommagé.

Pour cela, le composant Connexion.WSC possède une propriété appelée PATH indiquant le chemin du fichier info.txt. Comme les informations qui sont nécessaires pour la connexion existent dans un fichier, la fonction utilise certaines interfaces du composant “Scripting.FileSystemObject” pour ouvrir et lire le contenu de ce fichier (info.txt) et pour construire la chaine qui va être retournée par la fonction connexion.

5.5.3.2 Le composant Facture.WSC

Ce composant permet la gestion des factures. Pour cela, il fournie une interface contenant treize fonctions plus les trois interfaces des contrôleurs. Ces fonctions sont les suivantes.

La fonction insert_fact(num, four, montant, somme, date_fac) : elle permet d‟ajouter une facture à la table Facture. Pour cela, elle possède cinq paramètres qui représentent respectivement le numéro de la facture, le nom du fournisseur, le montant de la facture, le bénéfice et la date de facturation. Cette méthode retour true si l‟insertion est effectuer. Sinon elle retourne false.

La fonction getlistFact() : elle permet de retourner la liste de toutes les factures qui existent dans la table Facture. Si celle-ci est vide la fonction retourne une chaine de caractères vide.

La fonction insert_payement( num, somme, date, four) : elle permet d‟enregistrer une opération de payement d‟une facture. Pour cela, elle possède quatre paramètres qui représentent respectivement le numéro de la facture, le nom du fournisseur, le bénéfice et la date de facturation. Le numéro de payement est un nombre généré automatiquement par l‟SGBD. Cette méthode retour true si l‟insertion est effectuée et, s‟il y a une erreur, elle retourne la valeur false.

La fonction getFact_deux_date(date1, date2) : elle possède deux paramètres représentent deux date. Elle permet de retourner l‟ensemble des factures qui possèdent une date de facturation (date_fact) entre les deux dates fournies comme paramètres de la fonction. Dans le cas où il n‟y a aucune facture qui répond à cette condition, la fonction retourne une chaine de caractères vide.

La fonction getFact_deux_date_lim(date1, date2, num) : elle possède trois paramètres. Les deux premiers représentent deux dates, et le troisième représente un nombre entier. Cette fonction réalise les mêmes opérations effectuées par la fonction getFact_deux_date(). Elle retourne l‟ensemble des factures qui possèdent une date de facturation (date_fact) entre les deux dates fournies comme paramètres à la fonction. Notons que les factures sont ordonnées par date de facturation et cette fonction ne retourne pas toutes les factures trouvées, mais elle retourne seulement celles qui suivent un certain nombre indiqué par le paramètre num (par exemple les factures qui suivent les dix premiers factures et qui ont une date de facturation entre la date 01/01/2011 et la date 01/05/2011). S‟il n‟y a aucune facture qui répond à ces deux conditions, la fonction retourne une chaine de caractères vide.

La fonction getFact(num) : elle permet de rechercher une facture par son numéro qui est indiqué par le seul paramètre de cette fonction. Si la facture existe, la fonction retourne les différentes informations de celle-ci, sinon la fonction retourne une chaine de caractères vide.

La fonction getFact_nom(nom) : elle possède un seul paramètre qui représente le nom d‟un fournisseur. Elle permet de sélectionner les factures du fournisseur indiqué par le paramètre nom. S‟il y a des factures, la fonction retourne les différentes informations de celles-ci, sinon elle retourne une chaine de caractères vide.

La fonction getFact_nom_lim(nom_four, num) : elle possède deux paramètres où le premier représente un nom d‟un fournisseur et le deuxième un nombre entier positive. La fonction permet de sélectionner les factures du fournisseur indiqué par le paramètre nom_four. Cette fonction ne retourne pas tous les résultats obtenus. Elle retourne seulement les factures qui suivent le nombre indiqué par le paramètre num. Notons que les résultats sont ordonnés par ordre croissant des dates de facturation.

La fonction getFact_sof(num) : elle possède un seul paramètre qui représente un numéro d‟une facture. La fonction retourne la liste de toutes les factures enregistrées dans la base sauf celles qui ont le même numéro indiqué par le paramètre num.

La fonction getFact_lim(num) : elle possède un seul paramètre num et permet de retourner toutes les factures qui suivent le numéro num (par exemple, la liste de toutes les factures après les vingt premières factures). Notons que les factures sont ordonnées par ordre croissant selon les dates de facturation.

La fonction setFact( num, num1, nom, montant, ben, date) : elle permet de modifier une facture. Pour cela, elle possède six paramètres ; le premier représente l‟ancien numéro de la facture, le deuxième représente son nouveau numéro, le troisième représente le nouveau nom du fournisseur, le quatrième indique le nouveau montant, le cinquième indique le nouveau bénéfice et le sixième précise la nouvelle date de facturation. La fonction exécute une requête de modification. Si celle-ci est effectuée sans erreurs, elle retourne true sinon elle retourne false.

La fonction removeFact(num) : elle possède un seul paramètre qui représente le numéro de la facture que nous souhaitons supprimer. Si cette dernière existe, elle sera supprimée dans la table Facture et la fonction retourne la valeur true, sinon la fonction retourne la valeur false.

La fonction Facture_paye(num_fac) : cette fonction permet de retourner la liste des facture payées. Pour cela, elle effectue une jointure entre la table Facture et la table Payement_fact sur le numéro de facture, et calcule par la suite la somme du champ somme des enregistrements résultant. Si la somme est égale à la valeur du champ montant dans la table facture, la facture en question est une facture payée. Finalement, l‟ensemble de toutes les factures trouvées est retourné par la fonction.

5.5.3.3 Le composant Bl.wsc

Ce composant permet la gestion des BLs. Il fourni une interface composée de treize fonctions plus les trois interfaces des trois contrôleurs. Ces fonctions fonctionnent de la même manière que celles fournies par le composant Facture.WSC sauf qu‟elle manipule ici la table BL. Les sous-sections suivantes présentent et dérivent l‟implémentation de ces fonctions.

La fonction insert_BL(num,four,montant,somme,date_bl) : elle permet d‟ajouter un bon de livraison à la table BL. Pour cela, elle possède cinq paramètres qui représentent respectivement le numéro du BL, le nom du fournisseur, le montant du BL, son bénéfice et sa date. Cette méthode retour true si l‟insertion est effectuer, sinon elle retourne false.

La fonction getlistBL() : elle permet de retourner la liste de tous les BLs qui existe dans la table BL. Si celle-ci est vide la fonction retourne une chaine de caractères vide.

La fonction insert_Payement(num,somme,date,four) : elle permet d‟enregistrer une opération de payement d‟un bon de livraison. Pour cela, elle possède quatre paramètres représentant respectivement le numéro du BL, le nom du fournisseur, le bénéfice du BL et sa date. Le numéro du payement est un nombre généré automatiquement par le SGBD. Cette méthode retour true si l‟insertion est effectuée, sinon elle retourne une description de l‟erreur trouvée.

La fonction getBL_deux_date(date1,date2) : elle possède deux paramètres représentent deux dates. Elle permet de retourner l‟ensemble des BLs qui possèdent une date (date_bl) entre les deux dates indiquées par les deux paramètres date1 et date2. Dans le cas où il n‟y a aucun BL qui répond à cette condition, la fonction retourne une chaine de caractères vide.

La fonction getBL_deux_date_lim(date1,date2,num) : elle possède trois paramètres. Les deux premiers représentent deux dates, et le troisième est appelé num et qui représente un nombre entier. Cette fonction réalise les mêmes opérations effectuées par la fonction getBL_deux_date(). Elle retourne l‟ensemble des BLs qui possèdent une date (date_bl) entre les deux dates fournies comme paramètres à la fonction. Notons que les BLs sont ordonnés par date et cette fonction ne retourne pas tous les BLs trouvées, mais, elle retourne seulement ceux qui suivent un certain nombre indiqué par le paramètre num. S‟il n‟y a aucun BL qui répond à ces deux conditions, la fonction retourne une chaine de caractères vide.

La fonction getBL(num) : elle permet de rechercher un bon de livraison par son numéro. S‟il existe, elle retourne ses différentes informations, sinon, elle retourne une chaine de caractères vide. La fonction getBL_nom(nom) : elle possède un seul paramètre nom qui représente le nom d‟un fournisseur. La fonction permet de sélectionner les bons de livraison du fournisseur indiqué par le paramètre nom. S‟il y‟a des bons, la fonction retourne leurs différentes informations, sinon, elle retourne une chaine de caractères vide.

La fonction getBL_nom_lim(nom_four,num) : elle possède deux paramètres appelés respectivement nom_four et num. Le premier indique un nom d‟un fournisseur, alors que le deuxième indique un nombre entier positif. La fonction permet de sélectionner les bons de livraison du fournisseur indiqué par le paramètre nom_four. Elle ne retourne pas tous les résultats obtenus, mais elle retourne seulement les BLs qui suivent le nombre indiqué par le paramètre num. Notons que les résultats sont ordonnés par ordre croissant des dates date_bl.

La fonction getBL_sof(num) : elle possède un seul paramètre num qui représente un numéro d‟un bon de livraison. La fonction retourne la liste de tous les BLs enregistrés dans la base sauf celui qui a le numéro indiqué par le paramètre num.

La fonction getBL_lim(num) : elle possède un seul paramètre num qui représente un nombre entier positif. Elle permet de retourner tous les BLs qui suivent le nombre indiqué par le paramètre num. Notons que les BLs sont ordonnés par ordre croissant des dates (date_bl) (par exemple, tous les BLs qui suivent les dix premiers BLs).

La fonction setBL(num,num1,nom,montant,ben,date) : elle permet de modifier un bon de livraison. Pour cela, elle possède six paramètres ; le premier représente l‟ancien numéro du BL, le deuxième représente son nouveau numéro, le troisième représente le nouveau nom du fournisseur, le quatrième indique le nouveau montant, le cinquième indique le nouveau bénéfice et le sixième précise la nouvelle date du BL. La fonction exécute donc une requête de modification. Si celle-ci est effectuée sans erreurs la fonction retourne true sinon, elle retourne false.

La fonction removeBL(num) : elle possède un seul paramètre appelé num et qui représente le numéro du BL à supprimer. Si ce dernier existe dans la table B,L il sera supprimé et la fonction retourne la valeur true, sinon, la fonction retourne la valeur false pour dire que le BL n‟existe pas.

La fonction BL_paye(num_bl) : cette fonction permet de retourner la liste des BLs payés. Pour cela, elle effectue une jointure entre la table BL et la table Payement_bl sur le numéro du BL (num_bl). Par la suite, elle calcule la somme du champ somme des payements trouvés. Si celle-ci est égale à la valeur du champ montant dans la table BL, le BL en question est un BL payé. Finalement, la liste des BLs trouvés est retournée comme résultat par la fonction.

5.5.3.4 Le composant Recette.WSC

Ce composant permet la gestion des recettes. Pour cela, il fournit une interface composée des neuf fonctions suivantes :

La fonction insert_Recette(recette,date_rest) : elle permet d‟ajouter une recette à la table Recette. Pour cela, elle possède deux paramètres représentant respectivement la valeur de la recette et sa date. Le numéro de la recette est généré automatiquement par le SGBD. La date doit être vérifiée et validée avant l‟exécution de la requête de l‟insertion. Cette méthode retour true si l‟insertion est effectuée, sinon, elle retourne une chaine de caractères décrivant l‟erreur trouvée.

La fonction getlistRecette() : cette fonction permet de retourner la liste de toutes les recettes qui existe dans la table Recette. Si celle-ci est vide, la fonction retourne une chaine de caractères vide.

La fonction getRecette_deux_date(date1,date2) : elle possède deux paramètres appelés respectivement date1 et date2 représentant deux dates. Cette fonction permet de retourner l‟ensemble des recettes enregistrées entre les deux dates fournies comme paramètres à la fonction. Dans le cas où il n‟y a aucune recette qui répond à cette condition, la fonction retourne une chaine de caractères vide.

La fonction getRect_deux_date_lim(date1,date2,num) : elle possède trois paramètres. Les deux premiers appelés respectivement date1 et date2 représentant deux dates, et le troisième est appelé num et qui représente un nombre entier. Cette fonction réalise les mêmes opérations effectuées par la fonction getRecette_deux_date(). Elle retourne l‟ensemble des recettes qui possèdent une date (date_rect) entre les deux dates fournies comme paramètres à la fonction. Notons que les recettes sont ordonnées par ordre croisant des dates et cette fonction ne retourne pas toutes les recettes trouvées, mais, elle retourne seulement ceux qui suivent un certain nombre indiqué par le paramètre num. S‟il n‟y a aucune recette qui répond à ces deux conditions, la fonction retourne une chaine vide.

La fonction getRecette(date) : elle permet de rechercher une recette par sa date. Si la recette existe, elle retourne les différentes informations de celle-ci, sinon elle retourne une chaine de caractères vide.

La fonction getRecettte_lim(num) : cette fonction possède un seul paramètre num qui représente un nombre positif. Elle permet de retourner toutes les recettes qui suivent le nombre indiqué par ce paramètre (par exemple, toutes les recettes qui suivent les vingt premières recettes). Notons que les recettes sont ordonnées par ordre croissant de leurs dates.

La fonction set_Recette(recette,date,date1) : elle permet de modifier une recette. Pour cela, elle possède trois paramètres ; le premier représente la nouvelle valeur de la recette, le deuxième représente son ancienne date et le troisième représente sa nouvelle date. La fonction exécute donc une requête de modification. Si celle-ci est effectuée sans erreurs, elle retourne true, sinon, elle retourne une chaine de caractères décrivant l‟erreur trouvée.

La fonction remove_Recettet(num) : elle possède un seul paramètre num qui représente le numéro de la recette à supprimer. Si cette dernière existe, elle sera supprimée et la fonction retourne la valeur true, sinon la fonction retourne la valeur false pour dire que le numéro de la recette que nous voulons supprimer n‟existe pas dans la base.

5.5.3.5 Le composant Fournisseur.WSC

Ce composant permet la gestion des fournisseurs. Pour cela, il fournit une interface composée des fonctions suivantes :

La fonction insert_Four(nom,prenom,adr,type_pey) : elle permet d‟enregistrer un fournisseur dans la table fournisseur. Pour cela, elle possède quatre paramètres représentant respectivement le nom et le prénom du fournisseur, son adresse et son type de payement qui peut être par chèque ou par argent liquide. Le numéro du fournisseur est généré automatiquement par le SGBD. Les différents paramètres vont être vérifiés avant l‟exécution de la requête de l‟insertion. Cette méthode retour true si l‟insertion est effectuée, sinon, elle retourne une chaine de caractères décrivant l‟erreur trouvée.

La fonction getlistFour_nom() : cette fonction permet de retourner les noms de tous les fournisseurs enregistrés dans la table Fournisseur. Si celle-ci est vide, la fonction retourne une chaine de caractères vide.

La fonction gettousFour() : cette fonction n‟a aucun paramètre. Elle permet de retourner la liste de tous les fournisseurs qui existe dans la table Fournisseur. Si celle-ci est vide, la fonction retourne une chaine de caractères vide.

La fonction getFour(nom_four) : cette fonction a un seul paramètre qui indique le nom du fournisseur que nous cherchons. Elle permet donc de rechercher un fournisseur par son nom. Si ce dernier existe dans la base, la fonction retourne ses différentes informations, sinon, la fonction retourne une chaine de caractères vide pour dire que le fournisseur que nous cherchons n‟existe pas dans la base.

La fonction getFour_num(num) : elle permet de rechercher un fournisseur par son numéro. Pour cela, elle possède un seul paramètre appelé num qui représente le numéro du fournisseur recherché. Si ce dernier existe dans la base, cette fonction retourne ses différentes informations, sinon, elle retourne une chaine de caractères vide.

La fonction setFour(num,nom,prenom,adr,type_paym) : cette fonction permet de modifier un fournisseur. Pour cela, elle possède quatre paramètres ; le premier représente le numéro du fournisseur à modifier, le deuxième et le troisième représentent respectivement son nouveau nom et prénom, alors que le quatrième représente sa nouvelle adresse et le cinquième indique son nouveau type de payement. La fonction exécute donc une requête de modification. Si celle-ci est effectuée sans erreurs, elle retourne true, sinon, elle retourne une description de l‟erreur trouvée.

La fonction remove_Four(num) : elle possède un seul paramètre num qui représente le numéro du fournisseur à supprimer. Si ce dernier existe, il sera supprimé et la fonction retourne la valeur true, sinon, la fonction retourne la valeur false pour dire que ce fournisseur n‟existe pas.

5.5.3.6 Le composant Statistique.WSC

Ce composant permet de faire des statistiques concernant l‟état du magasin et l‟état des ventes dans le magasin. Pour cela, il fournit une interface composée de quatre fonctions, plus les trois interfaces qui représentent les trois contrôleurs CI, CS et CP. Ces fonctions sont les suivantes :

La fonction get_max_min_Recette() : elle permet de retourner la valeur maximale ainsi que la valeur minimale des recettes enregistrées dans la base. Pour cela, elle effectue une seule requête de sélection de ces deux valeurs à partir de la table Recette. Par la suite, elle parcourt les résultats et retourne les deux valeurs trouvées.

La fonction etat_mag_Fact() : elle permet de calculer la somme des bénéfices et la somme des coûts de l‟ensemble des factures enregistrées dans la base de données. Pour cela, elle exécute une requête de sélection des deux sommes à partir de la table Facture. A la fin, cette fonction retourne ces deux sommes.

La fonction etat_mag_Bl() : permet de calculer la somme des bénéfices et la somme des coûts de l‟ensemble des bons de livraison enregistrés dans la base de données. Pour cela, elle exécute une requête de sélection des deux sommes à partir de la table BL. A la fin, cette fonction retourne ces deux sommes.

La fonction etat_mag_Dep() : elle permet de calculer la somme des dépenses de l‟ensemble des dépenses enregistrées dans la base de données. Pour cela, elle effectue une requête de sélection de la somme des valeurs du champ montant de la table dépense. A La fin, la fonction retourne la somme trouvée.

5.5.3.7 Le composant Depense.WSC

Ce composant permet de faire la gestion des dépenses. Pour cela, Il fournit les fonctions suivantes :

La fonction insert_Dep(cause,montant,date) : elle permet d‟insérer une dépense dans la table dépense. Pour cela, elle possède trois paramètres représentant respectivement la cause de la dépense, son montant, et sa date. Le numéro de la dépense est généré automatiquement par le SGBD. La date est vérifiée et validée avant l‟exécution de la requête de l‟insertion. Cette méthode retourne true si l‟insertion est effectuée correctement, sinon, elle retourne une description de l‟erreur trouvée.

La fonction getlistDep() : elle permet de retourner la liste de toutes les dépenses qui existe dans la table Depense. Si celle-ci est vide, la fonction retourne une chaine de caractères vide.

La fonction getDep_deux_date(date1,date2) : elle possède deux paramètres qui représentent deux dates. Cette fonction permet de retourner l‟ensemble des dépenses enregistrées entre les deux dates fournies comme paramètres à la fonction. Dans le cas où il n‟y a aucune dépense qui répond à cette condition, la fonction retourne une chaine de caractères vide.

La fonction getDep_deux_date_lim(date1,date2,num) : elle possède trois paramètres. Les deux premiers représentent deux dates, et le troisième représente un nombre entier. cette fonction réalise les mêmes opérations effectuées par la fonction getDep_deux_date(). Elle retourne l‟ensemble des dépenses qui possèdent une date (date_dep) entre les deux dates (date1 et date2) fournies comme paramètres à la fonction. Notons que les dépenses sont ordonnées par ordre croissant des dates et cette fonction ne retourne pas toutes les dépenses trouvées. Elle retourne seulement celles qui suivent le nombre indiqué par le paramètre num. S‟il n‟y a aucune dépense qui répond à ces conditions, la fonction retourne une chaine de caractères vide.

La fonction getDep(num) : elle permet de rechercher une dépense par sa numéro. Pour cela, elle a un seul paramètre indiquant le numéro de la dépense recherchée. Si celle-ci existe, cette fonction retourne ses différentes informations, sinon, elle retourne une chaine de caractères vide.

La fonction getDep_lim (num) : cette fonction possède un seul paramètre appelé num et qui représente un nombre entier positif. Elle permet de retourner toutes les dépenses qui suivent le nombre indiqué par le paramètre num (par exemple, toutes les dépenses qui suivent les vingt premières dépenses). Notons que les dépenses sont ordonnées par ordre croissant de leurs dates.

La fonction setDep(num,cause,montant,date) : elle permet de modifier une dépense. Pour cela, elle possède quatre paramètres ; le premier représente le numéro de la dépense à modifier, le deuxième représente sa nouvelle cause, le troisième représente son nouveau montant et le quatrième sa nouvelle date. La fonction exécute donc une requête de modification. Si celle-ci est effectuée sans erreurs, la fonction retourne true, sinon, la fonction retourne une description de l‟erreur trouvée.

La fonction removeDep(num) : elle a un seul paramètre num qui représente le numéro de la dépense à supprimer. Si cette dernière existe, elle sera supprimée et la fonction retourne la valeur true, sinon, la fonction retourne la valeur false pour dire que la dépense n‟existe pas.

5.5.3.8 Le composant Adaptateur.WSC

Ce composant joue un rôle très important dans l‟application. C‟est lui qui est chargé d‟adapter les composants Facture.WSC, BL.WSC et Connexion.WSC, et représente donc l‟acteur de l‟adaptation dans l‟application. Il est même capable de s‟adapter automatiquement, ce qui implique qu‟il est lui aussi sujet de l‟adaptation. Ceci signifie que c‟est un composant auto-adaptatif.

Ce composant adapte le composant Connexion.WSC par la modification de la valeur de sa propriété PATH qui indique le chemin du fichier info.txt contenant les informations nécessaires pour l‟accès à la BDD (nom de la base et de son pilote, le nom d‟utilisateur et le mot de passe). Pour cela, il appelle la méthode setProp() de ce composant avec le nouveau chemin du fichier info.txt comme paramètre. Cette opération d‟adaptation est exécutée dans le cas où le fichier est endommagé ou n‟existe pas.

En fait, elle permet à l‟application de continuer à fonctionner même si ce fichier qui représente une ressource très importante pour toute l‟application est endommagé. Pour le composant Facture.WSC, la politique d‟adaptation consiste à modifier sa méthode de suppression d‟une facture. Donc, l‟opération effectuée est une opération de remplacement de la définition de la méthode removeFacture(). Actuellement, si cette méthode est appelée avec un numéro d‟une facture qui existe dans la base, cette dernière sera supprimée définitivement et aucune copie de celle-ci n‟est gardée.

La politique d‟adaptation consiste à remplacer le code de la méthode removeFacture() par un nouveau code qui permet de sauvegarder la facture dans l‟archive (la table Archive-Fact) avant sa suppression de la table Facture. Cette sauvegarde des factures avant de leurs suppressions est dans le but de faire des études et des statistiques sur celles-ci.

Pour la condition de l‟exécution de cette politique, nous avons choisi qu‟elle sera effectuée a partir d‟une date donnée. Le nouveau code de la méthode removeFacture() contient un appel à la méthode insertFact-archive() qui permet de rechercher la facture à supprimer et de l‟enregistrer dans la table Archive-Fact. Cette méthode n‟existe pas par défaut dans le code du composant Facture.WSC. Pour cella, nous devons l‟ajouter via un appel à la méthode addFuncIMP() du contrôleur de script avec son code comme paramètre.

Cette fonction (insertFact-archive()) contient elle même deux appels à deux fonctions get_mois() et decode_date(). La première a un paramètre qui est une chaine de caractère représentant un nom d‟un mois. Cette fonction retourne les deux chiffres qui représentent le mois décri par ce paramètre. La deuxième fonction (decode_date()) possède un seul paramètre date sous forme d‟une chaine de caractères indiquant une date.

Cette fonction transforme la date fournie comme paramètre à la forme AAAA-MM-JJ pour qu‟elle soit enregistrée correctement dans la base de données. Donc, ces deux fonctions doivent être ajoutées au code du composant Facture.WSC par deux appels à la fonction addFuncIMP(). De plus, les deux fonctions get_mois() et decode_date() nécessite pour leurs fonctionnement deux tableaux mois et mois_chiff.

Ces derniers contiennent douze éléments et représentent respectivement les mois en lettre et les mois en chiffre. Pour cela, ces deux tableaux doivent être ajoutés au code du composant en appelant la fonction addVarIMP() du contrôleur de script. Pour le composant BL.WSC, la politique d‟adaptation et la même que pour le composant Facture.WSC à la différence qu‟elle consiste ici à modifier la méthode de la suppression d‟un bon de livraison. Donc, l‟opération effectuée est une opération de remplacement de la définition de la méthode removeBL().

Actuellement, si cette méthode est appelée avec un numéro d‟un bon de livraison qui existe dans la base, ce dernier sera supprimé définitivement. La politique d‟adaptation consiste à remplacer le code de la méthode removeBL() par un nouveau code qui permet de sauvegarder le bon de livraison dans l‟archive (la table Archive-BL) avant sa suppression de la table BL. La sauvegarde des BLs avant leurs suppressions est aussi dans le but de faire des études et des statistiques sur ces derniers. La condition d‟exécution de cette opération d‟adaptation est la même que pour le composant Facture.WSC, c.à.d, elle sera effectuée a partir une date donnée (la même date pour l‟exécution de l‟adaptation du composant Facture.WSC).

Le nouveau code de la méthode removeBL() contient un appel à la fonction insertBL-archive() qui permet de rechercher le BL que nous souhaitons supprimer et de l‟enregistrer dans la table Archive-BL. Cette fonction n‟existe pas par défaut dans le code du composant BL.WSC. Pour cela, elle doit être ajoutée via un appel à la méthode addFuncIMP() du contrôleur de script du composant BL.WSC avec son code comme paramètre.

Cette fonction (insertBL-archive()) contient elle même deux appels à deux fonctions get_mois() et decode_date() décrites précédemment. Pour cela, ces deux fonctions et les deux tableaux mois et mois_chiff doivent être ajoutés au code du composant BL.WSC en utilisant aussi les deux méthodes addFuncIMP() et addVarIMP() de ce composant. Aussi, les deux tables Archive-Fact et Archive-BL doivent être crées via deux requêtes SQL, car elles n‟existent pas dans la base de données. La table Archive-Fact doit être crée avec la même structure que la table Facture et la table Archive-BL doit être crée avec la même structure que la table BL.

Nous avons dit précédemment que le composant Adaptateur.WSC est auto-adaptatif. Cela veut dire qu‟il est en même temps le sujet et l‟acteur de l‟adaptation. Il adapte les deux composants Facture.WSC et BL.WSC et, par la suite, il s‟adapte automatiquement par la modification de sa politique d‟adaptation qui est représentée par la fonction politique_apdate() que nous allons décrire dans la sous-section suivante :

La fonction politique_apdate() : cette fonction contient toutes les instructions qui permettent d‟adapter le composant Connexion.WSC et les deux autres composants Facture.WSC et BL.WSC.

Elle contient de plus, des instructions permettant de vérifier si les opérations d‟adaptation terminent correctement et permet aussi de vérifier si l‟application reste dans un état cohérant. Sinon, elle va faire un retour en arrière (Roll Back) en éliminant les effets de l‟exécution des adaptations, parce que la correction de l‟application est une condition très importante pour la validation de l‟adaptation. Voici le code de cette fonction :

Prog 5.4 Code source de la fonction politique_adapt().

Cette fonction exécute un test qui consiste à vérifier si le fichier info.txt existe dans le chemin indiqué par la propriété PATH du composant Connexion.WSC. Dans le cas où le fichier n‟existe pas dans ce chemin, la fonction politique_adapte() verifie l‟existance d‟une autre copie de ce fichier, et par la suite, adapte le composant Connexion.WSC par l‟appel de la méthode setProp() de ce composant avec le chemin de la copie du fichier trouvée comme paramètre. L‟exécution de cette méthode conduit donc à l‟adaptation de ce composant au changement de son contexte. Aussi, après l‟exécution de l‟adaptation, la fonction politique_adapte() appelle la méthode creat_copie() pour crié une nouvelle copie du fichier info.txt afin de remplacer la copie de ce fichier qui est supprimée ou endommagée.

Cette fonction exécute aussi un test qui consiste à vérifier si la date courante correspond à la date définie pour l‟exécution de l‟adaptation des deux composants Facture.WSC et BL.WSC. Si c‟est le cas, la fonction exécute un ensemble d‟instruction pour l‟adaptation de ces derniers. elle appelle pour cela la fonction update_FACT() pour l‟adaptation du composant Facture.WSC et la fonction update_BL() pour l‟adaptation du composant BL.WSC.

Comme l‟adaptation de ces composants consiste à ajouter des fonctions et des variables et aussi à remplacer les définitions de certaines fonctions par d‟autres, nous avons met le code de toutes ces fonctions et variables dans deux fichiers appelés respectivement update_fact.txt et update_bl.txt afin de réduire le code des deux fonctions update_FACT() et update_BL(). Par la suite, la fonction update_FACT() utilisent les opérations des interfaces du composant “Scripting.FileSystemObject” pour ouvrir et lire le fichier update_fact.txt afin d‟extraire la fonction removeFonction() et les deux autres fonctions getmois() et decode_date().

Après cette opération d‟extraction, la fonction fait un appel à la méthode Modif_Func() avec le nouveau code de la fonction removeFact() comme paramètre. De plus, la fonction appelle deux fois la méthode addFuncIMP() pour ajouter les codes des deux fonctions getmois() et decode_date(). La fonction update_BL() refait les mêmes opérations pour adapter le composant BL.WSC. elle ouvre et lie le fichier update_bl.txt pour extraire la fonction removeBL(). Par la suite, elle appelle la méthode Modif_Func() avec le code de la fonction removeBL() comme paramètre. Puis, la fonction appelle deux fois la méthode addFuncIMP() pour ajouter les codes des deux fonctions getmois() et decode_date() au composant BL.WSC.

Après l‟exécution de chaque fonction « update_FACT() et update_BL() » un ensemble d‟instructions qui permettent la vérification de la correction des deux composant Facture.WSC et BL.WSC et exécuté. Dans le cas où il y a des erreurs qui sont détectées le mécanisme de retour en arrière est appelé pour annuler les adaptations effectuées.

Voici le code de la fonction update_FACT() :

Prog 5.5 Code source de la fonction update_FANC().

Voici le code de la fonction update_BL() :

Prog 5.6 Code source de la fonction update_BL().

Nous avons dit précédemment que le composant Adaptateur.WSC est auto-adaptatif. pour cela, le fichier update_bl.txt contient en plus du nouveau code de la fonction removeBL(), le nouveau code de la méthode politique_apdate().

Après l‟exécution des opérations d‟adaptations des deux composants Facture.WSC et BL.WSC, la fonction politique_adapt() appelle la fonction update_adaptateur() pour adapter le composant Adaptateur.WSC. cette fonction (update_adaptateur()) appelle la méthode Modif_Func() du composant Adaptateur.WSC pour remplacer sa méthode politique_apdate() et par aussi trois appels à sa méthode removeFunction() pour supprimer ses fonctions ; update_FACT(), update_BL() et update_adaptateur(). Voici le code de cette fonction :

Prog 5.7 Code source de la fonction update_adaptateur().

L‟ancien code de la méthode politique_apdate() permet d‟adapter les trois composants Connexion.WSC, Facture.WSC et BL.WSC, alors que son nouveau code permet seulement d‟adapter le composant Connexion.WSC, c.à.d, il permet de modifier la valeur de sa propriété PATH. Si on ne fait pas cette modification, le test de la date reste toujours exécuté sans aucune importance, ce qui augmente automatiquement la complexité de l‟application.

De plus, les fonctions update_FACT(), update_BL() et update_adaptateur() ne seront pas utiles après cette adaptation, et donc, leurs suppression conduit à réduire le nombres de lignes du composant Adaptateur.WSC, ce qui conduit à réduire automatiquement la complexité du script.

Après l‟exécution des opérations d‟adaptation du composants Adaptateur.WSC lui-même, la méthode politique_apdate() vérifie si l‟adaptation se termine correctement et vérifie si l‟état de ce composant est cohérent ou non. Pour cela, elle va appeler la fonction test_correction() du composant Implementation-ScriptCOM(), et elle va tester le résultat renvoyé par cette fonction. Si le résultat est négatif, la fonction effectue un retour en arrière (Roll back).

Page suivante : 5.6 Conclusion

Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES