PROJET M1 SIGE (Inscription automatique au C2i) DOCUMENT D ANALYSE. Laurent BRIDELANCE Nicolas CAZIN Nicolas DOROTTE

Transcription

1 PROJET M1 SIGE (Inscription automatique au C2i) DOCUMENT D ANALYSE Laurent BRIDELANCE Nicolas CAZIN Nicolas DOROTTE

2 2 Table des matières 1 Analyse Présentation du problème Environnement Contraintes Choix des technologies et outils Technologies Outils Modèle à 3 couches Conception et Modélisation Cas d utilisation Point de vue Etudiant (Figure 3) Point de vue Correspondant UFR (Figure 4) Point de vue Administrateur (Figure 5) Diagrammes d activité Diagrammes de classes Diagramme préliminaire (Figure 10) Diagramme final (Figures 11 et 12) Diagrammes entité/association Diagramme préliminaire Diagramme final Implémentation Base de données Passage du schéma conceptuel à la création de la base Gestion des droits Procédures stockées Sauvegarde/Restauration Noyau c2i mail db daemons utils Interface Web Plan du site Gestion des requêtes Gestion de session

3 Connexion sécurisée Tests et Intégration du système Tests Organisation Tests des guides utilisateurs et d installation Performance du système Corrections et mises au point Driver JDBC Utilitaires Déploiement Limitations - Evolutions Interface Serveur Web Base de données Noyau Project management Development platform Development platform Security Problems Communication Meetings Mails, IM Wiki Tasks distribution and Gantt chart Analysis and modelling Implementation Documentation and tests Encountered difficulties A Appendix 51 B References 65 B.1 Bases de données B.2 J2EE B.3 J2SE B.4 Méthodologie UML

4 Analyse 4 1 Analyse 1.1 Présentation du problème Il s agit de concevoir et d écrire une application web permettant l inscription en ligne d étudiants à l examen du C2I et la gestion des horaires des sessions d examens auxquels ils s inscriront Environnement L environnement dans lequel va fonctionner notre application est le réseau local de l université de Cergy-Pontoise et par extension, l Internet. Plus exactement, l application va être hébergée sur un serveur HTTP. Nous verrons plus loin que le choix des technologies utilisées pour le développement va nous amener à modifier de façon mineure cet environnement, en particulier, le côté serveur Contraintes 1. Réutilisabilité La principale contrainte à respecter est celle de réutilisabilité. En effet, il est stipulé dans le cahier des charges que le système développé sera maintenu par des développeurs internes à l UCP les années suivantes. On veillera donc à utiliser des noms de variables pertinents, commenter abondamment le code, rédiger des documents et manuels propres et fonctionnels. Il est également important de concevoir de manière ouverte cette application et de ne pas faire d hypothèses simplificatrices concernant son l utilisation future. 2. Modularité Ce projet est à réaliser en groupe. Il est donc évident qu une structure modulaire est plus appropriée. De plus, une telle structure permet une maintenance aisée et facilite grandement la réutilisation. 3. Généricité L application doit être utilisable par n importe quel navigateur web. Ceci implique certains choix concernant les technologies utilisées et ne permet aucune hypothèse côté client. Nous considérerons le plus petit diviseur commun de ce que peut être un client web, à savoir un terminal léger minimaliste (faible résolution, peu de mémoire, peu de puissance de calcul et faible débit de transmission de données). La seule hypothèse que nous ferons est celle concernant le support de SSL par le navigateur (cf. HTTPS) qui n en est pas vraiment une étant donné que la très grande majorité des navigateurs supportent SSL (même les anciennes version).

5 Analyse Choix des technologies et outils Technologies 1. Servlets JAVA L utilisation d un langage objet s est imposée tout naturellement. La preuve de l utilité et de l efficacité de la conception objet n est plus à faire. L interface de notre logiciel se devant d être une interface web, nous nous sommes tournés vers JAVA et ses classes utilisables rapidement. Nous aurions pu utiliser des Applets, mais ce choix trop coûteux et lourd pour une application aussi simple a vite été rejeté. D une manière plus pragmatique, les Applets nécessitent l installation d un environnement JAVA sur chaque poste client. Ce qui est en contradiction avec la contrainte selon laquelle l application doit être accessible à partir de n importe quel navigateur. Les Servlets JAVA et JSP nous permettent toute la flexibilité et l efficacité dont nous avons besoin. Tant au niveau de l écriture des classes que de celle des pages web de l interface. La navigation est alors transparente, tout se passe comme si la page visitée était une page ordinaire. Les CGI quant à eux, malgré le fait qu ils permettent d utiliser divers langages de programmation, possèdent toutefois certains désavantages par rapport aux Servlets : on retiendra le fait qu un CGI est exécuté à chaque requête et que les CGI ne permettent pas les optimisations mises en œuvre par les Servlets : Mettre en cache des calculs précédents, garder une connexion avec une base de donnée ouverte. Notons qu il est également possible de partager des données entre Servlets. Un dernier point : l exécution d un Servlet JAVA se fait à l intérieur d une SANDBOX. Lorsqu un Servlet ou un Applet exécute une opération potentiellement dangereuse, l environnement demande au gestionnaire de sécurité l autorisation d exécuter son code. Si le code n est pas en adéquation avec la politique de sécurité de l environnement, l accès aux ressources systèmes n est plus autorisé. 2. Base de données et JDBC Il est fondamental pour une telle application de pouvoir assurer d une part la pérennité des données et d autre part l efficacité du traitement de ces dernières. Il est en effet impensable qu une inscription validée se retrouve erronée ou que les performances de l application s effondrent à cause du nombre d inscrits. L utilisation des pilotes JDBC se justifie quant à elle par le fait que la base de donnée installée sur le serveur n est pas définie. Les requêtes sont donc exécutées de manière standard, via le driver JDBC installé sur le système. Si la base de donnée venait à changer pour une raison ou pour une autre, seule la base de donnée serait à configurer. Aucune modification de l application ne serait nécessaire. De cette manière, les contraintes de réutilisabilité et de modularité sont respectées. Il est important de noter que la persistence des données peut être gérée d une manière bien différente. Avec les EJB, il est possible d implementer des classes JAVA et de faire en sorte que l accès à la base de données sous-jacente se fasse de manière transparente. En interne, les attributs de la classe sont mis en correspondance avec des attributs d une table de base de données. Dès lors qu une modification est opérée sur la classe, elle est répercutée sur la base de données. Bien qu à priori élégante, cette solution à deux inconveneant majeurs : l extrême lourdeur de la mise en oeuvre

6 Analyse 6 L utilisation des EJB nécessite d installer un service de plus (JONAS pour n en citer qu un), 4 fichiers supplémentaires par classe (2 fichiers JAVA, 2 fichiers XML) les performances Du fait de l utilisation d un service supplémentaire, les performances se voient déjà diminuées. Vient à s ajouter à cela la mise à jour instantanée de la base de données. Si pour une utilisation simple ceci encore acceptable, il est en revanche hors de question d utiliser des méthodes de mise à jour de manière intensive. Utiliser exclusivement des classes impose de traiter toutes les données au sein même de ces classes, dans les méthodes (services proposés à l interface utilisateur). Nous verrons plus loin qu il existe une autre alternative bien plus performante, taillée sur mesure et pas forcement moins élégante ou générique (notamment grâce à JDBC, le mécanisme d héritage de JAVA et les procédures stockées SQL). On se reportera à la section implementation. Un dernier choix que nous avons examiné puis rejeté est celui d utiliser ZOPE. Ce serveur est en fait un serveur d applications, capable évidemment de fonctionner avec des pages statiques et des bases de données relationnelles, mais aussi avec des bases de données objet. Chaque objet est stocké directement dans la base interne de ZOPE et les pages se programment d un façon peu commune. Cette technologie repose sur le langage PYTHON et nécessite donc un certain temps voir un temps certain de prise en main. Étant donné que nous n avons absolument aucune experience de programmation, encore moins de debugging sous PYTHON et que le temps imparti est limité, nous avons rejeté cette solution. 3. HTTPS Les données traitées sont à caractère personnel. Il est donc nécessaire de sécuriser l accès aux données. HTTPS permet de créer un canal sécurisé entre le client et le serveur. L utilisation de HTTPS est transparente. Toutes les requêtes sont traitées comme des requêtes ordinaires alors que les données transmises sont chiffrées grâce à un système de clefs. De plus, HTTPS est supporté par la grande majorité des serveurs HTTP. L utilisation de ce protocole reste en accord avec la contrainte de modularité. Les pages web et les Servlets sont ainsi développées indépendamment de la sécurisation des données. Bien que sécurisé, le protocole HTTPS est tout de même vulnérable aux attaques du type Man in the Middle : Ce genre d attaque est connu depuis un certain nombre d années et il existe bien Fig. 1 Schéma de l attaque Man in the middle

7 Analyse 7 évidemment un moyen de contourner ce genre d attaque. Grâce au SSL, le serveur Web est authentifié via un certificat X509 (l équivalent d une identité numérique). Ce certificat est signé par une autorité de certification (Certification Authority ou CA) reconnue internationalement et surtout par les navigateurs. Ainsi lorsqu un certificat n est pas conforme ou signé par une CA connue, le navigateur émet une alerte. 4. UML L intérêt d un tel formalisme est tout d abord de concevoir une application sans se soucier des détails d implémentation inhérents au langage de programmation utilisé. UML permet aussi de décrire avec beaucoup de pertinence une application, aussi bien aux programmeurs, concepteurs et utilisateurs, ce qui est assez rare et très utile. UML va donc nous permettre de nous concentrer sur la conception de notre application, tout en allant à l essentiel concernant sa documentation. D un point de vue plus pratique, UML va nous permettre de créer des diagrammes : bullet de cas d utilisation pour structurer les besoins des utilisateurs et les objectifs correspondant du système bullet d activité pour représenter graphiquement le comportement d une méthode ou d un cas d utilisation. (variante des états transition) bullet de déploiement pour présenter l architecture technique retenue. bullet de classes pour passer facilement à l implémentation avec un langage objet. De plus, le diagramme UML complet devant figurer dans la documentation, il est d autant plus judicieux de s appuyer sur UML pour concevoir notre application Outils 1. NetBeans En plus d être un IDE moderne et libre, NetBeans permet d implémenter, documenter du code JAVA avec une grande aisance ainsi que de tester des Servlets sans configurer explicitement un serveur HTTP adapté. Aussi, NetBeans propose un système de greffons (plugins), qui permettent entre autre de générer certaines parties de code à partir de diagrammes UML (squelettes des classes). 2. Visual Paradigm Ce logiciel qui se présente aussi sous la forme d un plugin de NetBeans, permet de Créer des diagrammes UML, de transformer du code JAVA en diagramme UML et inversement. Ceci nous permet de nous concentrer sur la conception du logiciel et de ne pas s attarder sur des interminables déclarations de classes et de variables. Ceci ne change en rien l écriture des méthodes en général, si ce n est le fait que tous les cas d utilisation sont prévus et gérés. Ce genre d outil présente un intérêt indéniable pour la conception et la réalisation de logiciels robustes. 3. Ant Ant est un outil qui permet de compiler du code source de manière efficace en gérant les dépendances vis à vis des fichier entre eux et ne recompilant que si nécessaire. C est un outil à la Make, basé sur JAVA, avec un certain nombre d inconveneants en moins. Pour n en citer qu un, les extensions de Make se font via le shell, qui est lui même dependant du système hôte. Ant quant à lui s étend grâce aux classes JAVA qui sont portables par définition. Un autre avantage est la souplesse dont fait preuve le parser de fichiers de configuration à l égard des fichiers :

8 Analyse 8 ceux de Ant sont Basés sur XML, ce qui implique la souplesse d utilisation liée à XML ainsi que l absence d apprentissage d un nouveau format de fichier. Enfin, Ant est intégré à NetBeans ce qui nous confère une utilisation efficace et unifiée de l IDE que nous avons choisi. Nous nous servirons donc de Ant pour écrire des scripts de déploiement de notre application. 4. JMeter JMeter est un outil JAVA de tests de montées en charge bien connu et éprouvé depuis plusieurs années (1998). Afin de prouver que nos choix technologiques sont pertinents et que notre application est parfaitement utilisable dans un cas réel, nous avons utilisé JMeter pour simuler différents types d utilisations avec plusieurs utilisateurs qui sont autant de Threads (processus légers) 5. JCrontab JCrontab est ni plus ni moins une version webapp du célèbre daemon UNIX : CRON. Il fonctionne exactement de la même manière, à la difference prêt que le contexte d execution est le conteneur de Servlet Tomcat. JCrontab est donc une application web au même titre que la notre. Elle nous permet d executer des tâches périodiques (maintenance ou avertissements par mail) et ceci quelque soit le système sur lequel est déployée notre application. 1.3 Modèle à 3 couches Suite à la lecture du sujet, 3 grandes parties se sont dégagées. Une première partie faisant office d interface entre l utilisateur et le système. Le sujet spécifie que l application doit être accessible depuis un navigateur internet, nous avons décidé de monter un site web remplissant cette fonction. La deuxième partie regroupe le stockage et l accès aux informations du système. La solution la plus efficace et rapide pour ce type de traitement est la mise en place d une base de données. Enfin, il nous fallait un moyen d encapsuler les requêtes transitant entre le serveur web et la base de données, nous avons donc développer une API servant d interface entre ces deux entités. Le diagramme suivant résume ce modèle à 3 couches : A partir de là,la répartition des tâches devient évidente. Chaque niveau n accédant à un autre que par le biais d une interface, nous avons décider d implémenter un niveau par personne. Remarque : nous n avons utilisé qu une seule machine pour notre système, regroupant le serveur web et le serveur de base de données, mais on voit bien que ces deux entités sont indépendantes et peuvent très bien être déployées sur des machines différentes (pour faciliter la maintenance ou minimiser les inconvénients en cas de panne par exemple).

9 Conception et Modélisation 9 Fig. 2 Modèle à 3 couches 2 Conception et Modélisation Nous avons vu plus haut que nous avons choisi UML lors de la phase de conception. C est donc tout naturellement que nous allons présenter ici notre conception sous forme de diagrammes qui sont autant de vues différentes du problème. Nous avons utilisé une démarche que l on pourrait qualifier de hiérarchique. Nous allons vous en présenter les couches successives. 2.1 Cas d utilisation Après plusieurs lectures attentives de l énoncé, la première étape de conception à été de définir clairement et définitivement les besoins des utilisateurs et les relations d interdépendances entre fonctionnalités. C est ici qu interviennent les diagrammes de cas d utilisation (Use case). Dans le soucis d une meilleure lisibilité, le diagramme d utilisation à été découpé en trois parties (un diagramme par rôle d utilisateur). Ils ne sont volontairement pas exhaustif, le but étant d avoir une idée claire du problème et non une implémentation directe Point de vue Etudiant (Figure 3) Point de vue Correspondant UFR (Figure 4) Point de vue Administrateur (Figure 5)

10 Conception et Modélisation 10 Fig. 3 Cas d utilisation pour l étudiant

11 Conception et Modélisation 11 Fig. 4 Cas d utilisation pour le correspondant

12 Conception et Modélisation 12 Fig. 5 Cas d utilisation pour l administrateur

13 Conception et Modélisation 13 On voit déjà apparaître une certaine structure redondante en observant ces diagrammes : 1 acteur 1 système d inscription 1 base de données Détaillons maintenant quelques unes de ces activités et tentons de dégager les concepts importants. 2.2 Diagrammes d activité Nous allons détailler certains cas d utilisation vus plus haut afin de faire ressortir les informations pertinentes pour la suite de la modélisation et de la conception. Certaines de ces activités pourront servir de base à l implémentation des méthodes mais ne constituent en aucun cas une implémentation complète. L implémentation sera en effet par moment différente pour mieux utiliser les spécificités des technologies que nous utilisons. Remarque : Tous les diagrammes d activité ne sont pas présentés ici afin d éviter de prendre de la place inutilement. Pour plus de détails reportez vous à l annexe. Seuls les activités principales sont représentées ici. On classe les activités par type d utilisateur du système : 1. Administrateur (a) Déléguer les droits Voir Figure 7 (b) Définir étendue créneau (c) Déterminer une date 2. Correspondant (a) Définir créneau Voir Figure 8 (b) Envoyer relance (c) Supprimer créneau (d) Vérifier candidats (e) Consulter Date 3. Etudiant (a) Créer compte candidat Voir Figure 9 (b) Modifier mot de passe 4. Mailer Daemon (a) Envoyer mail périodique 5. Système (a) Session (b) Requête (c) Envoyer un mail

14 Conception et Modélisation 14 Fig. 6 Diagramme d activité : Envoi mail périodique

15 Conception et Modélisation 15 Fig. 7 Diagramme d activité : déléguer les droits

16 Conception et Modélisation 16 Fig. 8 Diagramme d activité : définir créneau

17 Conception et Modélisation 17 Fig. 9 Diagramme d activité : créer compte candidat

18 Conception et Modélisation 18 Clairement, à la vue de la structure des couloirs d activités et des activités utilisées de manière répétitive, on note déjà le besoin d un système qui fait usage de formulaires pour transmettre la saisie utilisateur au système, d une base de données pour stocker de manière pérenne et sûre les informations gérées par le système, et de mails pour notifier les utilisateurs des changements. Ce qui est cohérent avec nos choix technologiques. 2.3 Diagrammes de classes Nous allons maintenant voir la modélisation en diagramme de classe de notre application. Nous ne présenterons ici que la partie principale du noyau, à savoir le package c2i, pour les autres packages, veuillez vous referrer à l annexe. Nous verrons deux versions de ce diagramme. La première version ayant été réalisée après lecture de l énoncé, pendant la phase de modélisation. La seconde reflétant l état du package à la fin du développement Diagramme préliminaire (Figure 10) Fig. 10 Diagramme préliminaire

19 Conception et Modélisation 19 Le diagramme préliminaire comme on peut le voir est composé des principales ressources utilisées dans le système c est-à-dire : User, Student, Correspondent, Admin, Site, Classroom, Timeslot. Cela représente en fait une quasi-relation de un vers un avec la base de donnée. En effet, chaque entité du diagramme est un accès vers une table dans la base de donnée. Celles-ci sont composées principalement d accesseurs get et set vers un attribut de la table correspondante. De plus, leur contenu est implémenté à l aide de requête SQL. On note aussi d autres méthodes importantes telles que createtimeslot, logon,... qui correspondent elles à l implémentation des fonctions que doit réaliser notre système. Ce diagramme représente donc l objectif idyllique final que l on souhaite atteindre mais évidemment il ne tient pas compte de la réalité de l implémentation. C est ce que corrige le version final du diagramme suivant Diagramme final (Figures 11 et 12) Le diagramme final comme nous le disions auparavant tient compte lui de la réalité de l implémentation. Ceci se traduit tout d abord par le fait que la plupart des accesseurs set ont disparu puisqu ils n étaient pas utilisés. La classe Reminder a fait son apparition, elle gère le système d envoi de mail lorsqu une notification a lieu d être par exemple à la suite de la suppression d un créneau. Les classes Site, Classroom et Timeslot en dérivent. On a aussi un changement majeur : la classe Admin dérive de Correspondent car nous nous sommes aperçu qu un administrateur est aussi un correspondant du système. Pour conclure, le diagramme de classes final emploie pratiquement les mêmes entités et relations que le premier hormis deux changements, mais la plus grosse différence provient du contenu des classes qui a changé pour tenir compte des nouvelles fonctionnalités ajoutées au système.

20 Conception et Modélisation 20 Fig. 11 Package c2i (première partie)

21 Conception et Modélisation 21 Fig. 12 Package c2i (deuxième partie) 2.4 Diagrammes entité/association Cette partie présente la première phase de la conception de la base de donnée. Deux diagrammes sont présentés : Un diagramme préliminaire qui représente le premier schéma stable qui a été proposé. Un diagramme final qui tient compte des modifications qui ont été nécessaires pour l implémentation.

22 Conception et Modélisation Diagramme préliminaire Fig. 13 Diagramme ER Initial

23 Conception et Modélisation Diagramme final Fig. 14 Diagramme ER Final

24 Implémentation 24 3 Implémentation Après avoir modélisé notre système, il nous reste maintenant à l implémenter. Notre application étant divisée en 3 niveaux, nous allons voir 3 grandes parties expliquant ces différents niveaux, où chacun d entre nous expliquera le travail qu il a fourni. 3.1 Base de données Dans cette partie, nous allons introduire la mise en place de la base de données. Comme précédemment exposé, le choix s est porté sur une base PostgreSQL plutôt que MySQL car cette dernière ne supporte pas certaines caractéristiques intéressantes telles que les vues ou le support total des contraintes (clause CHECK). De plus PostgreSQL est très proche de la norme ANSI SQL, ce qui n est pas le cas de MySQL. En ce qui concerne les transactions, PostgreSQL les intègre automatiquement sur toutes les tables alors que dans MySQL celles-ci doivent être déclarées en innodb. De plus PostgreSQL supporte depuis longtemps les procédures stockées, alors que cette caractéristique vient juste d être implémentées dans MySQL et donc nous ne possèdons pas du recul suffisant. C est donc tout naturellement que le choix s est porté sur PostgreSQL Passage du schéma conceptuel à la création de la base La première étape du travail est de passer du schéma entité-relation à la création de la base de données. Un ensemble d utilitaires est fourni avec la distribution de PostgreSQL. En l occurrence une application createdb permet de concevoir la base facilement. Une fois ceci fait un script dbcreate.sql a été conçu à partir du modèle ER présenté plus haut. Maintenant, il s agit d envoyer ce script vers la base. Cela se fait simplement en utilisant la commande client psql de cette manière : psql nom de base -f nom du script A présent, nous possédons les outils pour concevoir physiquement notre base de données. Expliquons maintenant comme passer du schéma à un ensemble de commandes SQL : Chaque entité dans le modèle ER est convertie en une table dans la base de données à l aide de la commande SQL : CREATE TABLE nom entité ( liste attributs ) ; où liste attributs représente les attributs de l entité avec leurs types et d éventuelles contraintes.

25 Implémentation 25 Exemple : Création de la table USER C2I CREATE TABLE USER_C2I ( login VARCHAR(16) NOT NULL PRIMARY KEY, password VARCHAR(255) NOT NULL, VARCHAR(255) NOT NULL CHECK( LIKE %@%.% ), rights CHAR(1) NOT NULL, logged BOOL NOT NULL DEFAULT FALSE, is_validated BOOLEAN NOT NULL DEFAULT FALSE, CHECK (rights IN ( A, S, C, 0 )) ); Sur cet exemple, on peut noter l emploi d un certain nombre de contraintes : Contrainte de domaine : Réaliser à l aide de CHECK pour vérifier si une valeur est bien dans un ensemble. Contrainte de non-nullité : Réaliser à l aide de NOT NULL. Cet attribut a toujours une valeur. Contrainte unicité de clé : Ici réaliser par la clé primaire login. On ne peut avoir deux utilisateurs avec le même login. Les relations sont traduites à l aide de tables dans la base de données. Ces tables contiennent des clés étrangères vers les entités qu elles relient, plus des attributs si nécessaire. Example : Relation USER IS STUDENT CREATE TABLE USER_IS_STUDENT ( nip VARCHAR(8) NOT NULL, login VARCHAR(16) NOT NULL, FOREIGN KEY (nip) REFERENCES STUDENT(nip) ON DELETE CASCADE, FOREIGN KEY (login) REFERENCES USER_C2I(login) ON DELETE CASCADE, UNIQUE(nip), UNIQUE(login) ); Ainsi cette relation lie les entités STUDENT et USER C2I. On ajoute donc deux clés étrangères qui pointent vers les clés primaires de chacune de ces deux tables. De plus, pour avoir l unicité de la relation on ajoute aussi deux contraintes de dépendances fonctionnelles sur les attributs nip et login Gestion des droits Création des utilisateurs Un travail important a été fourni sur la gestion des droits d accès à la base de données. Dans un premier temps quatre utilisateurs sont crées : user c2i, student, admin, correspondent. En effet, quand un utilisateur se connecte sur le site et qu il rentre son login/password,

26 Implémentation 26 le compte user c2i est utilisé pour vérifier l exactitude du compte. Ensuite s il s agit d un étudiant le compte student sera utilisé, de la même manière pour admin et correspondent. Cette méthode nous a permis de limiter les droits d accès à la base de données et éviter d éventuels piratages de la base de données. En effet, un compte student n a pas les mêmes privilèges * qu un compte admin. Pour créer un utilisateur, on utilise la commande suivante : CREATE USER nom utilisateur WITH PASSWORD mot de passe ; Attribution des droits Présentons les principaux type de droits : SELECT : Permet de faire des lectures sur des tables. INSERT : Permet de faire des ajouts de lignes dans une table. UPDATE : Permet de faire des modifications de lignes dans une table. DELETE : Permet de faire des suppressions de lignes dans une table. Pour mettre des droits à un utilisateur, on utilise la commande suivante : GRANT droits ON nom table TO nom utilisateur ; Procédures stockées Dans un premier temps, nous avons développé un certain nombre de fonctions dans le noyau. Mais au fil du temps, celle-ci se sont avérées compliquées à écrire et surtout de multiples requêtes étaient effectuées. Ce dernier point ralentissait considérablement le fonctionnement du système. Pour introduire le language à utiliser dans la base de données la commande createlang est utilisé : createlang plpgsql nom de base Ainsi, nous avons décidé d utiliser pleinement les fonctionnalités du SGBDR et de transposer les fonctions en procédures SQL dans le language pl/pgsql. Ce dernier n est autre qu un language composé des requêtes standards SELECT, IN- SERT, etc... augmenté des notions de variables, tests, et boucles. Du coté noyau, on appelle simplement la procédure qui fait le même travail mais coté base de données. D où un gain de performance énorme. Exemple : La procédure Logon /* This function is the base of the login system. It takes two parameters login and password. It returns a character which represents the rights of the user or # if the user is already connected */ CREATE OR REPLACE FUNCTION logon(varchar(16), VARCHAR(255)) RETURNS CHAR(1) AS $BODY$ DECLARE