par
Pierre Konopacki
Memoire presente au Departement d'informatique en vue
de l'obtention du grade de maitre es sciences (M.Sc.)
FACULTE DES SCIENCES
UNIVERSITE DE SHERBROOKE
Sherbrooke, Quebec, Canada, fevrier 2008
1*1
Published Heritage Branch 395 Wellington Street Ottawa ON K1A0N4 Canada Direction du Patrimoine de I'edition 395, rue Wellington Ottawa ON K1A0N4 CanadaYour file Votre reference ISBN: 978-0-494-42970-9 Our file Notre reference ISBN: 978-0-494-42970-9
NOTICE:
The author has granted a non-exclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by
telecommunication or on the Internet, loan, distribute and sell theses
worldwide, for commercial or non-commercial purposes, in microform, paper, electronic and/or any other formats.
AVIS:
L'auteur a accorde une licence non exclusive permettant a la Bibliotheque et Archives Canada de reproduire, publier, archiver,
sauvegarder, conserver, transmettre au public par telecommunication ou par Plntemet, prefer, distribuer et vendre des theses partout dans le monde, a des fins commerciales ou autres, sur support microforme, papier, electronique et/ou autres formats.
The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.
L'auteur conserve la propriete du droit d'auteur et des droits moraux qui protege cette these. Ni la these ni des extraits substantiels de celle-ci ne doivent etre imprimes ou autrement reproduits sans son autorisation.
In compliance with the Canadian Privacy Act some supporting forms may have been removed from this thesis.
Conformement a la loi canadienne sur la protection de la vie privee, quelques formulaires secondaires ont ete enleves de cette these. While these forms may be included
in the document page count, their removal does not represent any loss of content from the thesis.
Canada
Bien que ces formulaires
aient inclus dans la pagination, il n'y aura aucun contenu manquant.
lejury a accepte le memoir e de M. Pierre Konopacki dans sa version finale.
Membres dujury
M. Marc Frappier Directeur
Departement d'informatique
Mme Sandrine Blazy Membre externe
- Institut d'informatique d'Entreprise
M. Luc Lavoie President-rapporteur Departement d'informatique
Dans le cadre de developpement de systemes d'informations, les methodes formelles de specification peuvent reduire le developpement aux seules phases d'analyse et de conception. La methode EB3 est une de ces methodes. Elle se base sur une algebre de processus dont les
actions peuvent etre gardees. Une garde permet de soumettre leur execution a une condition. Les gardes sont des expressions logiques definies sur les attributs des entites du systeme. Ces attributs sont stockes dans une base de donnees relationnelle. Ce memoire presente un algorithme qui permet de generer une implementation en Java et SQL des gardes d'une specification EB3. II est implemente dans EB3GG, un outil integre dans la plateforme APIS,
plateforme qui supporte la methode EB3. Dans ce memoire, nous presentons l'algorithme
elabore pour realiser la traduction des definitions de gardes vers du code executable et son implementation.
Nous definissons les operateurs du langage de description des gardes. L'algorithme detaille dans ce memoire se base sur la description de ce langage aim d'implementer les operateurs en utilisant une forme normale definie a partir d'un sous-ensemble des operateurs des gardes.
Je tiens a remercier mon directeur de recherche, le Professeur Marc Frappier qui m'a donne l'opportunite d'effectuer une maitrise au sein de son Groupe de Recherche en Ingenierie du Logiciel (GRIL). Je souhaite aussi le remercier pour l'encadrement et les conseils qu'il m'a apportes tout au long de l'annee, et qui m'ont permis de mener a bien mon projet. Je le remercie egalement de m'avoir place dans les meilleures conditions de travail et d'avoir mis a ma disposition tout le materiel necessaire a ma recherche.
Je suis egalement tres reconnaissant aux membres du laboratoire GRIL de m'avoir ac-cueilli si chaleureusement.
Je tiens particulierement a remercier M Frederic Gervais de m'avoir fait partager ses connaissances sur la methode EB3 et le langage d'attributs, pour son aide a la redaction de
ce memoire.
Mes remerciements vont aussi a M Benoit Fraikin pour son apport de connaissances sur la methode EB3 et les algebres de processus.
Je tiens a remercier les etudiants avec qui j'ai pu partager le laboratoire du GRIL. Je remercie l'Universite de Sherbrooke, son personnel administratif et ses professeurs pour leur accueil et leur encadrement.
Enfin, mes remerciements vont aussi a l'ENSIIE qui m'a permis d'effectuer ma troisieme annee ici, a Sherbrooke.
I n t r o d u c t i o n 1 Contexte 1 Objectif 2 Methodologie 2 Resultats 3 Plan du memoire 3 1 E t a t de P a r t 5 1.1 DjangoProject 6 1.1.1 Concepts de base 6 1.1.2 Le module de generation de l'API 7
1.1.3 Avantages et inconvenients 7
1.2 Ruby On Rails 8 1.2.1 Concepts de base 8
1.2.2 Traduction O-R 9 1.2.3 Avantages et inconvenients 9
1.3 Spring et outil de traduction O-R 10
1.3.1 Spring 10 1.3.2 Les outils de traduction O-R 11
1.4 Comparaisons des cadriciels precedents 14
2 Plateforme APIS 16 2.1 Principe de fonctionnement 16
2.2 La methode EB3 17
2.2.1 Diagramme E-R et sa traduction dans la base de donnees 18
2.2.2 Principe de fonctionnement 25 2.2.3 Les expressions de processus dans la methode EB3 26
2.2.4 Gardes en EB3 29
2.3 Limites de la plateforme APIS 34 3 Algorithme de traduction des gardes vers du code executable 37
3.1 Principe de fonctionnement general 37 3.1.1 Analyse syntaxique et lexicale 39
3.1.2 Verification semantique 39 3.1.3 Normalisation de la structure interne 39
3.1.4 Mise en place des requetes 42 3.1.5 Passage de la representation objet a l'implementation 43
3.2 Regie de traduction en Java 43 3.2.1 Les operateurs terminaux 44 3.2.2 Les operateurs unaires 45 3.2.3 Les operateurs binaires 46 3.2.4 Les quantifications 48 3.2.5 Ensembles dermis par extension 50
3.2.6 Appartenance a un ensemble defini par extension 51
3.3 Regies de traduction en SQL 51
3.3.1 Patron E.k 53 3.3.2 Patron E.k(x) 54
3.3.3 Patron E.k(xi,... , Xj) 56 3.3.4 Composition des patrons E.k(x) et E.k(xi,... ,^2) 56
3.3.5 Appartenance a un ensemble dont revaluation se fait en SQL 58
3.3.6 Traduction des representations objets des requetes 59 3.3.7 Les quantifications faisant intervenir des ensembles decrits a l'aide de
patrons 63 3.4 Preuve de completude 65
3.5 Complexite du code genere 70
4 Implementation 71
4.1 EB3GG 71
4.2 Architecture de l'outil 74 4.3 Integration dans la plateforme APIS 76
5 Cas d'etude 78 Conclusion 87
Evaluation critique des Resultat 88
Travaux futurs 88 A Diagrammes de classe de la representation objet 90
B Grammaire des gardes EB3 93
1.1 Fonctionnement de JDO 14 2.1 Fonctionnement de la Plateforme APIS 18
2.2 Diagramme E-R de I'exemple de la bibliotheque 21
2.3 Exemple d'enonce de creation de table 25 2.4 Processus main de I'exemple de la bibliotheque 27
2.5 Processus member de I'exemple de la bibliotheque 28 2.6 Processus book de I'exemple de la bibliotheque 28 2.7 Processus loan de I'exemple de la bibliotheque 28 2.8 Processus loan utilisant une garde dans I'exemple de la bibliotheque 29
2.9 Grammaire utilisee pour Vexpression des gardes en EB3 35
2.10 Grammaire utilisee pour V'expression des gardes en EB3 (suite) 36
3.1 Exemple de transformation de garde ne faisant pas intervenir d 'ensemble . . 48 3.2 Exemple de transformation de garde ne faisant pas intervenir d 'ensemble . . 52
3.3 Exemple d'utilisation du patron E.k 54 3.4 Illustration des entites intervenant dans le Patron E.k(x) 54
3.5 Exemples d'utilisation du patron E.k(x) 55 3.6 Exemples d'utilisation du patron E.k(x) 57 3.7 Exemple d'utilisation du patron E.k 59
3.8 Exemple d'utilisation du patron x G E.k 60 3.9 Exemple d'implementation du patron E.k de la figure 3.3 62
3.10 Exemples d 'implementation du patron E.r{x) de la figure 3.5 63 3.11 Exemple d'implementation du patron x 6 E.k de la figure 3.8 64 3.12 Grammaire utilisee pour decrire la representation des gardes suite a la
nor-malisation EB3 66
3.13 Grammaire utilisee pour decrire la representation des gardes suite a la
nor-malisation EB3 (suite) 67
3.14 Grammaire utilisee pour decrire la representation des gardes suite a la mise
en place des requetes EB3 68
3.15 Grammaire utilisee pour decrire la representation des gardes suite a la mise
en place des requetes EB3 (suite) 69
4.1 Fonctionnement du module EB3GG 72
4.2 Exemple de fichier contenant des definitions de garde 73 4.3 Exemples de fichier de sortie contenant des implementations de garde . . . . 74
4.4 Exemples de fichier de sortie contenant des implementations de garde (suite) 75 4.5 Exemples de fichier de sortie contenant des implementations de garde (suite) 76
5.1 Fichier d'entree du cas d'etude 79 5.2 Figure montrant le resultat de I'algorithme de normalisation sur Vexemple du
cas d'etude 80
5.3 Figure montrant le resultat de I'algorithme de normalisation sur Vexemple du
cas d'etude 80
5.4 Fichier de sortie du cas d'etude 81 5.5 Fichier de sortie du cas d'etude (suite) 82
5.6 Fichier de sortie du cas d'etude (suite) 83 5.7 Fichier de sortie du cas d'etude (suite) 84
5.8 Fichier de sortie du cas d'etude (suite) 85 5.9 Fichier de sortie du cas d'etude (suite) 86
Contexte
De nos jours, le traitement de l'information necessite de plus en plus de moyens humains et logiciels. La mise en relation de ces moyens concourt a la creation de systemes d'informations. L'utilisation de tels systemes permet d'automatiser le traitement de l'information. Dans ce memoire, nous ne nous interessons qu'a la composante logicielle des systemes d'informations. Leur utilisation est largement repandue, mais les developpeurs sont souvent amenes a devoir reimplementer la moindre fonctionnalite. Pour realiser le developpement de systemes d'infor-mations, des outils specifiques peuvent etre utilises, mais ils demandent un effort important de developpement.
Une autre possibilite est d'utiliser des specifications formelles qui reduisent le developpe-ment d'applications uniquedeveloppe-ment aux phases d'analyse et de specification des besoins. Ensuite le developpement peut etre entierement automatise a l'aide d'outils ne se basant que sur les resultats de ces deux phases. L'utilisation de telles methodes est appreciee dans le develop-pement d'applications critiques, car elles permettent de realiser une application repondant mieux aux attentes et aux besoins enonces lors des phases d'analyses et de specifications des besoins. Dans le domaine des systemes d'informations, la methode EB3 est une methode de
specification formelle utilisee dans l'automatisation de developpement de systemes d'infor-mations.
d'informations est basee sur une algebre de processus, qui permet toutefois de garder les actions, c'est-a-dire de conditionner l'execution d'une action a l'aide d'une expression logique definie sur l'etat du systeme.
Notre projet consiste a generer automatiquement un programme permettant d'evaluer les gardes d'une expression de processus. Ces gardes peuvent faire reference aux attributs des entites qui sont stockes dans une base de donnees relationnelle.
Objectif
L'objectif de nos travaux est de fournir une methode permettant d'implementer les gardes presentes dans les expressions de processus. Pour elaborer cette methode, nous de-vons d'abord determiner le langage permettant de decrire les gardes. Une fois ce langage determine, nous etablissons un algorithme permettant de passer de l'expression d'une garde a son implementation. Une fois ces gardes implementees, nous modifions l'interpreteur de processus pour qu'il puisse utiliser leur implementation afin de les evaluer.
Methodologie
La premiere etape du travail consiste en une recherche bibliographique. Cette recherche a permis de voir de quelle maniere se realise la simplification de la couche d'acces aux don-nees dans divers cadriciels de developpement de logiciel. Notre travail consiste ensuite en la definition du langage utilise pour definir les gardes au sein de l'algebre de processus. Pour cette definition, nous avons selectionne les operations que nous desirions pouvoir utiliser dans l'expression d'une garde. La formalisation du langage utilise pour la definition des gardes a ete realisee en ordonnant ces operateurs a l'aide d'une grammaire. Pour realiser l'implemen-tation, nous devons etablir des regies permettant de traduire chacun des operateurs dans un langage executable. Pour cela, nous avons determine les operateurs qui pouvaient etre
les langages d'implementation SQL et Java et propose des regies de traduction vers ces lan-gages. L'etablissement de ces regies a abouti a l'etablissement d'un algorithme permettant de traduire une expression de garde en langage executable. Finalement, l'outil cree a du etre integre aux autres composantes de la plateforme APIS. Cette integration a ete possible apres la redefinition du langage de description des algebres de processus dans le but d'y inclure les operateurs de gardes et la modification de l'interpreteur d'expressions de processus pour qu'il utilise les implementations de ces gardes afin de les evaluer. L'integration du nouvel outil au sein de la plateforme APIS a egalement necessite la realisation de tests de maniere a s'assurer que les outils deja existants n'ont pas perdu de fonctionnalites, mais aussi que les nouvelles fonctionnalites s'executent correctement.
Resultats
Nous avons obtenu un outil, appele EB3GG, permettant d'automatiser l'implementation
d'un langage d'interrogation de base de donnees fonde sur un modele entite-relation(E-R). Cet outil permet, dans le cadre de 1'evaluation d'une garde, d'interroger une base de donnees en ne connaissant que le modele E-R de la specification. De plus, il a permis d'ajouter a l'interpreteur de processus de la plateforme APIS la capacite d'interpreter des processus dont les actions sont gardees. Les resultats ont pu etre utilises afin de realiser un cas d'etude. Ce cas d'etude permet de mettre en evidence la plupart des difficultes rencontrees lors du developpement de EB3GG.
Plan du memoire
Dans le chapitre 1, nous detaillons l'etat de l'art qui nous a permis d'apprendre comment se realisent les etapes d'interrogation de la source de donnees dans plusieurs outils de deve-loppement de logiciels. Dans le chapitre 2 nous passons en revue la plateforme APIS et aussi
mentation automatique de gardes en un langage executable. Au chapitre 4, nous detaillons l'implementation de cet algorithme au sein de la plateforme APIS. Dans le chapitre 5, nous illustrons l'application de l'algorithme sur un cas d'etude. En conclusion, nous portons un regard critique sur nos resultats et identifions des prolongements potentiels de nos travaux.
Etat de Part
Dans ce chapitre, nous nous interessons a differents environnements de travail qui per-mettent d'aider au developpement de systemes d'informations, en realisant a partir de la description de plusieurs caracteristiques du systeme d'informations une partie du code de maniere automatique. Pour simplifier le traitement des acces en ecriture et lecture a la base de donnees, le programmeur peut utiliser une API (Application Programming Interface). L'API correspond a un ensemble de fonctions qui realisent la traduction entre les donnees utilisees sous forme d'objets dans le programme et leur representation dans la base de don-nees. Ce mecanisme de traduction est aussi appele mapping Objet-Relationnel ou mapping O-R. L'utilisation d'une API permet de rajouter une couche d'abstraction dans le develop-pement du systeme d'informations.
Dans le cadre de developpement de systemes d'informations, differents frameworks (en frangais cadriciel) peuvent etre utilises. Les cadriciels permettent grace a l'utilisation d'une API adaptee au langage utilise de simplifier la phase de developpement. Les cadriciels Djan-goProject, Ruby On Rail et Spring bases sur des langages de progranimation differents sont presentes dans la suite de ce chapitre.
1.1 DjangoProject
DjangoProject a ete cree en 1995 et porte son nom en l'honneur de Django Reinhardt. Dans cette section, nous detaillons le principe de fonctionnement de ce premier cadriciel et plus particulierement la fagon dont il gere les acces a la base de donnees. Enfin nous donnons les avantages et les inconvenients inherents a son utilisation.
1.1.1 Concepts de base
DjangoProject [8] est un cadriciel permettant de creer des logiciels de gestion de systemes d'informations. Cet outil se base sur le langage de programmation Python. Python est un langage de programmation type et interpreted II a ete cree en 1989 par Guido van Rossum [9], qui lui donna ce nom en l'honneur de ses idoles les « Monthy Python ». Python est un langage de programmation oriente objet mais il permet aussi de programmer dans un style fonctionnel.
Le cadriciel utilise les entrees suivantes.
• Les regies de traduction O-R permettent de faire le lien entre la base de donnees et les classes utilisees dans l'interface. Elles permettent de realiser une API utilisable dans l'application entiere. Cette API est generee a l'aide d'un fichier, realise par le programmeur, contenant l'ensemble des classes Python dont les instances doivent etre sauvegardees sur la base de donnees
• Les regies de comprehension des URL permettent au programmeur de definir la ma-niere dont doivent etre interpreters les donnees contenues dans l'URL. Ces regies de traduction se basent principalement sur l'utilisation d'expressions regulieres.
• Les modeles de pages HTML correspondent a la mise en page des informations conte-nues dans la base de donnees et devant etre affichees. lis correspondent a une combi-naison de code HTML et de code Python faisant intervenir principalement les classes dont la sauvegarde est assuree par l'API.
LOTS de l'utilisation d'un systeme d'informations cree a l'aide de DjangoProject, un
mo-dule fonctionne en permanence et utilise les regies de traduction decrites precedemment afin de pouvoir creer les pages HTML necessaires pour repondre aux besoins des utilisateurs. Ces pages seront generees a partir des modeles dermis par le programmeur et des donnees recuperees dans les differentes URL.
1.1.2 Le module de generation de l'API
Lors de la creation d'une application de gestion de systemes d'informations, Django-Project genere une API, sans recourir directement a un langage d'interrogation de base de donnees comme le langage SQL. Ceci est possible grace a la traduction O-R utilisee par Djan-goProject. L'API met en relation les differents attributs des instances presentes en memoire avec la base de donnees.
Pour que cette traduction soit realisable, la maniere dont l'API doit mettre en relation les objets en memoire et la base de donnees doit etre explicitee. Cette mise en relation est faite lors de la declaration des classes utilisees par l'application.
Lors de la declaration d'une classe, les elements devant etre sauvegardes dans la base de donnees doivent etre declares avec des types speciaux fournis par le cadriciel. Ces types permettent a DjangoProject de creer une API compatible avec la plupart des SGBD. Cette API contient les requetes dites CRUD c'est-a-dire les requetes correspondant a des Create,
Read, Update ou Delete.
1.1.3 Avantages et inconvenients
L'outil DjangoProject genere une API utilisable dans l'ensemble de l'application. Cette API permet la communication avec le systeme d'informations. II faut declarer une ou plu-sieurs classes contenant les donnees que Ton veut rendre persistantes. L'avantage est que le programmeur n'a plus a se soucier de la communication entre le programme et la base de
donnees, cette derniere est entierement encapsulee par l'API generee. Bien que simplifiant l'acces a la base de donnees, l'API generee ne realise que les requetes de base et ne prend pas en compte les requetes complexes.
1.2 Ruby On Rails
Ruby On Rail1 est egalement un cadriciel permettant de developper des systemes
d'in-formations. Ruby On Rail est base sur le langage de programmation Ruby. II s'agit d'un langage de programmation objet qui permet de faire de la programmation procedurale. Le langage Ruby a vu le jour en 1995 et peut etre considere comme une version orientee objet du langage de programmation PERL [7].
Nous detaillons l'architecture de ce cadriciel et la maniere dont il realise la traduction O-R.
1.2.1 Concepts de base
Lors de la creation d'un systeme d'informations avec Ruby On Rails le programmeur commence par preciser la definition de la base de donnees. Le programmeur a done la charge de definir les tables de la base de donnees ainsi que leur liens. Ensuite le cadriciel permet de generer automatiquement les fichiers permettant d'utiliser les donnees contenues dans la base de donnees. Ces fichiers correspondent a la traduction de ces donnees vers des objets utilisables par l'ensemble de l'application. lis correspondent a l'API fournie par le cadriciel. Cette API prend en charge les requetes simples de lecture, de modification, d'ajout et de suppression. Les relations entre les differentes tables utilisees dans la base de donnees doivent etre indiquees dans ces fichiers.
Le cadriciel genere des fichiers contenant une combinaison de Ruby et d'HTML, ces fichiers correspondent a des modeles qui permettent de mettre en page les donnees contenues
dans la base de donnees.
Ruby On Rails permet d'eviter les repetitions. Pour acceder a des donnees ou les mettre en page, l'application utilise les fichiers precedemment generes. Ces fichiers peuvent etre modifies pour realiser le travail de maniere plus adequate. Ce cadriciel se base sur un principe de convention. En effet, dans les fichiers generes correspondant a l'API, le programmeur peut faire apparaitre les differentes relations presentes dans la base de donnees en se referant a celle-ci a l'aide de conventions. Ces conventions evitent de declarer de nouveaux fichiers de configuration representant les liens entre les termes utilises pour decrire la base de donnees et ceux figurant dans les definitions de classes manipulees dans le reste de l'application.
1.2.2 Traduction O-R
Pour realiser la traduction entre les objets utilises et la base de donnees, Ruby offre un comportement par defaut qui respecte le principe d'utiliser des conventions plutot que des configurations. Ces conventions portent sur le nom donne aux differentes tables et aussi a leurs attributs. Par exemple, si un attribut porte le nom d'une autre table, prefixe par "key" alors les contraintes de cle etrangere sont generees automatiquement. Ce comportement permettra au developpeur d'acceder a la base de donnees de maniere transparente. Cette configuration par defaut de Ruby On Rail permet l'ajout, la suppression et la modification de donnees dans la base de donnees que l'utilisateur aura congue lui meme.
1.2.3 A vantages et inconvenient s
Pour realiser la traduction O-R, le programmeur definit des classes qui lui permettent de recuperer les donnees dans la base de donnees qu'il cree. Le programmeur peut facilement reutiliser des bases de donnees deja existantes si toutefois ces dernieres respectent quelques conventions. Les methodes de modifications et de lectures simples de la base de donnees sont deja creees par Foutil Ruby On Rail, mais le programmeur est libre de les redefinir afin
qu'elles soient mieux adaptees a 1'application.
1.3 L'environnement de developpement Spring et les
outils de traduction O-R
Dans cette section, nous nous interessons a la creation d'une API au sein d'une application realisee en Java. Le developpement d'un tel module peut etre simplifies grace a l'utilisation d'outils de deux categories differentes.
Les outils de la premiere categorie permettent de mettre en relation les differents elements composant l'application. lis prennent en charge leur definition et leur creation. Les outils de la seconde categorie permettent de rendre des objets persistants en les mettant en relation avec la base de donnees.
L'outil Spring appartient a la premiere categorie, les outils Hibernate et JDO appar-tiennent quant a eux a la seconde categorie.
1.3.1 Spring
Dans le cadre de creation de logiciels de gestion de systemes d'informations realises en Java, le cadriciel Spring peut jouer le role d'infrastructure en prenant en charge la creation et la mise en relation d'objets (voir [6] et [10].). Cette prise en charge se fait grace a un fichier de configuration detaillant les objets a construire et les relations qui lient ces objets.
Pour mettre les elements en commun Spring utilise 1'IOC (Inversion Of Control) [3]. L'inversion de controle permet de rendre le programme plus robuste en supprimant des liens de relation structurelle entre les classes. Par exemple, si dans le logiciel que Ton desire creer, une classe A contient un attribut appartenant a la classe B, dans la definition de la classe A on fera apparaitre un attribut appartenant a une classe B qui ne sera pas implemented sous ce nom. Dans la configuration de Spring les classes A et B sont declarees. De plus, le fichier de configuration fait apparaitre que la classe A possede un attribut de la classe B. Dans ce
fichier on precise la classe implemented qui joue le role de la classe B. Lors de l'initialisation de l'outil Spring, les instances de A et B seront creees et le cadriciel Spring se chargera d'aifecter a l'instance de A l'instance de B. La classe A peut alors posseder un attribut dont elle ne connait pas la classe. De plus la classe B n'est pas obligee d'implementer une interface comme dans le cas d'une inversion de controle (IOC) realisee sans l'outil Spring.
Les cadriciels tels que Spring peuvent done etre utilises dans le cadre d'exploitation de base de donnees. Leur efficacite est encore amelioree s'ils sont utilises avec des outils se chargeant exclusivement de la traduction O-R entre les classes mises en place par le cadriciel et les donnees contenues dans le systeme d'informations.
1.3.2 Les outils de traduction O-R
Dans cette section nous presentons deux outils pouvant realiser la traduction O-R entre les objets utilises par l'application et leurs images dans la base de donnees.
H i b e r n a t e
Dans le cadre du developpement de logiciel de gestion de systemes d'informations, l'outil Hibernate s'interesse a la couche du logiciel qui correspond a Faeces aux donnees. Cette couche du logiciel permet d'interfacer le reste de l'application avec la source de donnees, les donnees sont alors pergues par le reste du logiciel comme des objets persistants. Ce travail peut etre realise par un programmeur et demande des efforts repetitifs entre les differentes applications et dans le cas d'un changement de sources de donnees. L'outil Hibernate per-met de simplifier la realisation de cette couche de l'application en realisant les operations d'ecriture et de lecture.
II permet de realiser la persistance des objets de l'application de differentes fagons. L'uti-lisateur peut employer comme source de donnees, aussi bien des fichiers crees selon la norme XML que des bases de donnees. Les pilotes necessaires a leur fonctionnement doivent etre fournis par l'utilisateur.
Pour realiser ces acces aux donnees, Hibernate doit connaitre la maniere dont les classes Java vont etre associees aux differents elements de la source de donnees. Cette correspondance est precisee a l'aide d'un fichier au format XML appele fichier de mapping. Un autre fichier est necessaire au bon fonctionnement d'Hibernate, il s'agit d'un fichier qui lui precise les donnees techniques concernant la source de donnees. II indique s'il s'agit d'une base de donnees ou alors d'un fichier au format XML et aussi les differentes informations necessaires a leur utilisation (comme l'adresse du serveur et le nom de Putilisateur dans le cas d'une base de donnees).
Dans le reste de l'application afin de lire les donnees, le programmeur instancie les classes decrites dans le fichier de mapping. Cette instanciation sera realisee a l'aide du langage HQL. HQL est un langage d'interrogation qui ressemble au SQL mais qui est propre a l'outil Hiber-nate. Le programmeur possede un ou plusieurs objets contenant des informations presentes dans la source de donnees. Ces objets peuvent etre utilises en lecture. lis peuvent aussi etre utilises en ecriture avant d'etre sauvegardes de maniere a changer les informations contenues dans la source de donnees. Pour ajouter des informations dans la sources de donnees, le programmeur cree une instance vide d'une classe decrite dans le fichier de mapping, afin d'y placer les valeurs qu'il souhaite ajouter dans la source. Cette instance est ensuite sauvegardee et les valeurs supplement aires ont ete ajoutees a la source de donnees.
JDO
Dans le cadre de developpement d'applications en Java, le developpement de persistance se fait generalement au detriment de la simplicite des objets utilises. Les POJO (Plain Old
Java Object) sont alors souvent remplaces par des objets plus complexes.
La norme JDO (Java Data Object) permet de definir une capacite de persistance aux objets simples, mais de maniere transparente pour l'utilisateur. De plus, la norme JDO ne specifie pas le support sur lequel doit se realiser la persistance, elle peut done etre faite sur un SGBDR (Systeme de Gestion de Bases de Donnees Relationnelles), un SGBDO (Systeme de
Gestion de Bases de Donnees orientees Objets), un fichier eventuellement ecrit selon la norme XML. JDO etant une norme, elle subit des restrictions lors de ses differentes implementations, qui se distinguent alors en trois categories principales :
• implementations ne supportant que les SGBDR , • implementations ne supportant que les SGBDO , • implementations supportant tout type de support.
Pour rendre cette persistance possible et transparente de maniere a etre utilisee sur des objets POJO, les objets sont rendus persistants apres leur compilation par une modification du bytecode (c.f. : figure 1.1). Ce principe de persistance divise alors les objets en trois categories :
• Non-enhanced : Les objets qui n'ont pas d'attributs persistants et qui n'interagissent pas sur les attributs persistants d'autres classes,
• Persistent-capable : Les classes dont les objets sont persistants ou dont les donnees peuvent etre modifiees par des transactions,
• Persistent-aware : Les classes qui ne sont pas persistantes elles-memes, mais qui uti-lisent des attributs persistants d'autres classes.
Le principal probleme de cette methode provient des classes persistent-aware. Dans la pra-tique pour limiter le nombre de classes aware, les attributs des classes
persistent-capable vont etre declares comme etant prives, la lecture et l'ecriture de ses attributs sont
realisees a l'aide de methodes et les classes utilisant ces methodes peuvent etre declarees comme des classes Non-enhanced.
1.3.3 A vantages et inconvenient s
L'utilisation de ces outils permet de creer un logiciel dont les differentes couches applica-tives sont bien separees. Ces outils simplifient la mise en place de la couche de persistance des donnees et de la couche de presentation des donnees. Les differentes couches mises en place sont alors dependantes des outils utilises lors de leur creation. Les nouvelles versions de ces
Code source Compilateur Java 9 Byte code JDO enhancer i > i ' Mapping (fichier XML) Byte mrio Java |VM y B D JDO Driver F I G . 1.1 - Fonctionnement de JDO
outils doivent rester compatibles avec les travaux realises grace aux versions precedentes. De plus les outils comme Hibernate permettent de mieux gerer la base de donnees, par exemple en definissant soi-meme la traduction O-R, mais demandent un plus grand effort de confi-guration a l'utilisateur. Au contraire l'outil JDO demande moins d'efforts de conficonfi-guration de la part du programmeur mais ne permettra pas de definir la maniere dont sera realisee la traduction entre les objets et le support pour les donnees.
1.4 Comparaisons des cadriciels precedents
Les API generes par DjangoProject, Ruby On Rails, l'utilisation des outils Spring en col-laboration avec Hibernate ou un outil implementant la norme JDO permettent de simplifier les couches logicielles de persistance et de presentation des donnees dans le developpement d'un systeme d'informations. Grace a ces outils, l'implementation de ces couches est facilitee par l'automatisation de certaine taches.
Pour la realisation de la couche de persistance l'utilisation de schemas relationnels de base de donnees n'est pas encore possible. En effet, le programmeur utilisant ces outils doit indiquer la maniere de relier les differents attributs des classes utilisees dans l'application aux differents attributs des tables de la base de donnees.
le reste de l'application. Cette centralisation est utilisee dans les cadriciels DjangoProject et Ruby On Rails. Elle peut etre realisee dans une application Java en utilisant le cadriciel Spring. Ces differentes aspects sont regroupes au sein du tableau 1.1.
Les outils precedents permettent d'implementer automatiquement des methodes d'inter-rogation simple de bases de donnees, c'est-a-dire des requetes de creation, de lecture, de mise-a-jour ou de suppression. Aucune de ces methodes ne permet d'automatiser l'imple-mentation de requetes plus complexes dont la definition serait donnee a l'aide d'expressions ecrites dans un langage formel de specification. Nous decrivons dans ce memoire un outil permettant de realiser un tel travail.
TAB. 1.1 - Comparaison —-___^^ methodes concepts ^~~~~~~---_____^ DjangoProject Ruby On Rails Spring Hibernate JDO generation d'une API oui oui non oui oui traduction O-R non non non partiellement partiellement fonctions complexes dans l'API non non non partiellement partiellement prise en charge des objets oui oui oui non non
Plateforme APIS
Dans ce chapitre nous nous interessons a un autre cadriciel de developpement de sys-temes d'informations et de leurs interfaces web. Au contraire des environnements de travail precedents, celui-ci est base non pas sur un langage de programmation mais sur un langage formel de specification specialise dans la description de systemes d'informations, la methode EB3. La plateforme APIS permet de developper un systeme d'informations et son interface
web grace a une specification realisee a l'aide de la methode EB3.
2.1 Principe de fonctionnement
En EB3, la description d'un systeme d'informations comporte plusieurs parties :
• Specification de l'interface homme-machine : cette partie definit de maniere precise l'interface graphique,
• Diagramme Entite-Relation (E-R) : il represente les differentes entites utiles a la specifi-cation et les associations intervenant entre elles. La definition detainee de ce diagramme sera donnee au chapitre 2.2.1,
• Definitions recursives d'attributs : elles permettent de calculer l'etat du systeme en fonction d'une trace valide du syteme,
• Regies d'Entree-Sortie : elles definissent la sortie associee a chacune des entrees pos-sibles,
• Expressions de processus : elles decrivent la maniere dont les actions peuvent se suc-ceder les unes aux autres au sein du systeme d'informations. Pour exprimer cet ordon-nancement, une algebre de processus est utilisee au sein de la methode EB3.
Ces differents elements vont etre utilises par les differents modules de la plateforme APIS afin de realiser un systeme d'informations et son interface web specifies dans la description.
• Le module DCI-WEB genere l'interface graphique a partir de la specification de l'in-terface homme-machine
• EB3TG est un module qui utilise le diagramme E-R et les definitions d'attributs, afin de
generer pour chaque action EB3 un programme Java. Ce programme Java correspond a
une transaction pour la base de donnees. Cette transaction implemente les definitions d'attributs de la specification du systeme d'informations(voir [2]). Cet outil se charge aussi d'implementer un programme Java qui permet de creer et d'initialiser la base de donnees du systeme d'informations. Lors de la creation de ce programme l'outil EB3TG
realise la traduction du modele E-R vers un modele relationnel selon un algorithme etabli dans [1]
• EB3PAI est un interpreteur pour Palgebre de processus EB3 (voir [4]). De plus, il assure
la coherence entre la trace acceptee par le systeme et la base de donnees.
Le fonctionnement de la plateforme APIS ainsi que les connexions entre ses modules sont presentes dans la figure 2.1.
2.2 La m e t h o d e EB
3Dans cette section nous decrivons le langage formel utilise par la plateforme APIS et son principe de fonctionnement.
H i
Ingenieur
Spit ilu Minn (III ivsliim- il'iiirnriiijIliiiiM
S:w. • i.! II V, .W l'11'll-ll..LC l)i.':'.i.i.iii"t* I :il ' c K^'a'.kHi Dvl'iniM. .1-J.ill ihils -I i— • 4 t D C I - W c l i > Kt„lc> J r r . r n > Will!.-. Kxprcssions de processus i ^ _ F.BT« j - - •
J,
Utilisateur — I I ...• Interface Web * 1 Mnsacuons Je mibc a jour Base de ilnnn j « :Environnemciil d'ciecution du svslcme d'lnronnations
^ Entree / Sortie _ ^ . Generc _ ^ Execute
V
F I G . 2.1 - Fonctionnement de la Plateforme APIS
2.2.1 Diagramme E-R et sa traduction dans la base de donnees
Le modele entite-relation, aussi appele entite-association, propose des concepts permet-tant de decrire un ensemble de donnees relatives a un domaine donne afin de les integrer dans une base de donnees relationnelle ou objet. Dans la suite de ce chapitre, l'ensemble des concepts du modele E-R pris en charge par l'outil EB3TG et l'algorithme permettant latraduction du modele E-R en schema de base de donnees relationnelle sont presenter.
Concepts du modele E-R
Les concepts suivants sont ceux pris en charge par l'outil EB3TG, ils sont aussi reutilises
dans la definition des gardes.
Entite et type d'entite Un type d'entite regroupe les entites qui possedent les memes caracteristiques. Une entite est un objet concret ou abstrait qui peut etre reconnu
distincte-ment. Par exemple, dans un modele entite-relation representant une bibliotheque, l'ensemble des livres de cette bibliotheque constitue le type d'entite tandis qu'un livre est une entite, c'est-a-dire une instance du type d'entite. Dans un modele entite-relation n'apparaissent que des types entites. Par abus de langage, on utilise souvent le mot entite en lieu et place du mot type d'entite.
Un type d'entite qui a sa propre clef candidate est qualifie de fort alors que celui qui en herite, par le biais d'une relation, est qualifie de faible.
Attribut Un attribut est une caracteristique associee a un type d'entite. Dans l'exemple de la bibliotheque, l'entite livre possede un titre, qui est l'un de ses attributs.
Un attribut peut cependant etre simple ou compose. Un attribut est dit compose lorsqu'il est constitue de plusieurs attributs simples. Un attribut simple est une caracteristique ato-mique. L'attribut titre par exemple est un attribut simple. Considerons toujours le domaine de la bibliotheque. La date de retour d'un livre emprunte peut etre decomposed en annee, mois, jour et heure. II s'agit alors d'un attribut compose.
Par ailleurs, si pour une entite donnee, un attribut peut prendre plusieurs valeurs, alors cet attribut est dit multivalue. Par exemple, un membre d'une bibliotheque peut avoir plusieurs numeros de telephone. Le numero de telephone est alors un attribut multivalue.
Lorsqu'un attribut identifie de facon unique une entite, cet attribut est dit clef candidate. II peut y avoir plusieurs clefs candidates pour un type d'entite donne.
Relation Une relation, encore appelee association, correspond a un lien entre plusieurs entites. Dans le cas d'une bibliotheque, on pourra permettre aux membres d'emprunter des livres en creant une relation loan entre les entites membre et book. La relation loan ne fait intervenir que deux entites, elle est dite binaire. Les relations faisant intervenir plus de deux entites sont dites n-aire.
Role Chaque type d'entite participant a une relation joue un role. Par exemple dans le cas de la relation loan les membres jouent le role d'emprunteur appele borrower.
Cardinality La cardinality est un concept s'appliquant aux relations. Dans l'exemple de la bibliotheque un membre peut emprunter plusieurs livres a la fois, mais un livre ne peut etre emprunte que par une seule personne a la fois. Pour la relation loan la cardinality de l'entite correspondant aux livres est alors (0,1), c'est-a-dire qu'un livre peut soit ne pas etre emprunte soit etre emprunte par une seule personne. Pour la relation loan la cardinality de l'entite correspondant aux membres sera (0,N), c'est-a-dire qu'un membre emprunte plusieurs livres ou aucun. Pour simplifier la notation de la cardinality, on ne conserve que la cardinality maximale des entites intervenant, ainsi la cardinality de la relation loan est notee 1 :N. Les relations de cardinality 1 :1 ou M :N sont definies de la meme fagon.
Donnons maintenant un exemple de specification EB3 en utilisant un systeme simple
de gestion de bibliotheque. Cette specification met en commun les differentes illustrations des concepts du modele E-R. L'exemple traite utilise deux types d'entites representant les membres et les livres. La relation entre ces deux entites permet de representer la capacite qu'ont les membres d'emprunter des livres. La figure 2.2 donne le diagramme E-R represen-tant ce systeme.
Traduction du modele E-R vers une base de donnees relationnelle
Dans cette partie nous detaillons 1'algorithme utilise par le module EB3TG. Cet algorithme,
decrit dans [1], permet de faire le lien entre le schema E-R et la base de donnees relationnelle qui lui est associee. II est reutilise lors de l'implementation automatique des gardes. Plu-sieurs schemas de bases de donnees relationnelles peuvent correspondre a un modele E-R. Dans la definition des gardes l'utilisateur peut mentionner des elements apparaissant dans le diagramme E-R. Lors de l'implementation des gardes, il est imperatif de suivre le meme algorithme de traduction de maniere a interroger la base de donnees pour les elements cites
book -bookKey: numeric (5.2) - t i t l e : VARCHAR(503 +Acquire() +Discard{) * loans loan -dueDate: Date +LendH +Return() 0..1 borrower member -member-Key: numeric(5) -nbloans: numeric(5} -name: varchar(2Q) +Register() +Unregister()
F I G . 2.2 - Diagramme E-R de I'exemple de la bibliotheque
dans les definitions des gardes. La figure 2.3 montre le resultat de cet algorithme applique a I'exemple simple de gestion d'une bibliotheque presente a la figure 2.2.
L'algorithme de traduction s'effectue en trois phases realisees dans l'ordre suivant : 1. les types d'entite forts
2. les types d'entite faibles 3. les relations
Cet ordre permet d'apporter une solution au probleme de migration des clefs primaires qui ne sont pas connues dans le modele E-R.
Traduction des types d'entites forts Pour chaque type d'entite fort Er
creer une table tr ;
inclure les attributs simples de ET ;
inclure les attributs simples des attributs composes de Er ;
choisir une des clefs candidates de Er comme clef primaire;
declarer les autres clefs candidates comme clefs uniques; pour chaque attribut multivalue M de Er
Traduction des types d'entites faibles Pour chaque type d'entite faible Ew
creer une table tw ;
inclure les attributs simples de Ew ;
inclure les attributs simples des attributs composes de Ew ;
pour chaque type d'entite parent Pw de Ew
si un type d'entite fort ou un type d'entite faible deja traduit inclure la clef primaire de Pw ;
definir la clef primaire de tw comme etant la combinaison
de sa clef partielle et de la clef primaire de Pw ;
aj outer une contrainte de clef etrangere qui reference tr ;
pour chaque attribut multivalue M de Ew
traduire M en utilisant la table tw; (1)
sinon
traduire le parent Pw ;
traduire Ew;
Traduction des relations
Traduction des relation 1 :1 Pour chaque relation R de type 1 :1
soient S et T les types d'entite participant a R; soient s et t leurs tables respectives;
si S = T (relation reflexive)
dupliquer et renommer la clef primaire ; inclure les attributs simples de R dans s;
inclure les attributs simples des attributs composes de R dans s;
ajouter une contrainte de clef etrangere qui reference s ; pour chaque attribut multivalue M de R
traduire M en utilisant la table s ; (1) sinon si S a une participation totale dans R
ajouter la clef primaire de t a s ;
inclure les attributs simples de R dans s;
inclure les attributs simples des attributs composes de R dans s ;
pour chaque attribut multivalue M de R traduire M en utilisant la table s; (1) sinon
aj outer la clef primaire de s a t;
inclure les attributs simples de R dans t;
inclure les attributs simples des attributs composes de R dans t;
ajouter une contrainte de clef etrangere qui reference s; pour chaque attribut multivalue M d e i ?
traduire M en utilisant t; (1)
Traduction des relations 1 :N Pour chaque relation R de type 1 :N
soient S et T les types d'entite participant a R; soient s et t leurs tables respectives;
on suppose que S a la cardinalite N; si S = T (relation reflexive)
dupliquer et renommer la clef primaire; ajouter les attributs simples de R dans s;
ajouter les attributs simples des attributs composes de R dans s ;
ajouter une contrainte de clef etrangere qui reference t; pour chaque attribut multivalue M de R
traduire M en utilisant la table s ; (1) sinon
ajouter la clef primaire de t a s; ajouter les attributs simples de R a s;
ajouter les attributs simples des attributs composes de R a s;
ajouter une contrainte de clef etrangere qui reference t; pour chaque attribut multivalue M de R
traduire M en utilisant la table s; (1)
Traduction des relations M :N Pour chaque relation R de type 1 :N
soient s et t leurs tables respectives; creer une table tmn ;
inclure les attributs simples de R dans tmn ;
inclure les attributs simples des attributs composes de R dans tmn ;
aj outer les clefs primaires de s et t; s i S = T
renommer les clefs primaires;
definir la clef primaire de tmn comme etant
la combinaison des deux clefs primaires;
ajouter deux contraintes de clef etrangere qui referencent s et t; pour chaque attribut multivalue M de R
traduire M en utilisant la table tmn ; (1)
Traduction d'une relation n-naire Pour chaque relation R de type n-aire
creer une table tn ;
inclure les attributs simples de R dans tn ;
inclure les attributs simples des attributs composes de R dans tn ;
inclure les clefs primaires de toutes les tables participant a R; definir la clef primaire de tn comme etant la combinaison
de toutes les clefs primaires;
ajouter une contrainte de clef etrangere pour chaque clef primaire importee;
pour chaque attribut multivalue M de R traduire M en utilisant la table tn; (1)
Traductions des attributs multivalues
Pour traduire les attributs multivalues a l'aide d'une table t on utilise l'algorithme (1) suivant :
creer une table tm ;
inclure un attribut A correspondant a M; ajouter la clef primaire de t a tm ;
et de la clef primaire de t; si M est compose
inclure les attributs simples de M;
aj outer une contrainte de clef etrangere qui reference t;
CREATE TABLE book ( bookKey numeric(5,2), title varchar(50),
CONSTRAINT PKbook PRIMARY KEY(bookKey));
CREATE TABLE member ( memberKey numeric(5), nbLoans numeric(5) NOT name varchar(20),
NULL,
CONSTRAINT PKmember PRIMARY KEY(memberKey));
CREATE TABLE loan ( borrower numeric(5), bookKey numeric(5,2), dueDate date,
CONSTRAINT PKloan PRIMARY KEY(bookKey));
F I G . 2.3 - Exemple d'enonce de creation de table
2.2.2 Principe de fonctionnement
La methode EB3 est une methode de specification formelle de systemes d'informations.
Elle permet de decrire le fonctionnement du systeme a l'aide d'une algebre de processus. Une specification EB3 comporte une expression de processus notee main. A partir de cette
expression de processus on peut definir l'ensemble des traces acceptees par le systeme, c'est-a-dire l'ensemble des listes d'evenements qu'il accepte.
La semantique d'une specification EB3 est donnee par une relation R definie sur T(main) x
et O l'ensemble des evenements a la sortie du systeme. Soient t r a c e la liste des evenements valides acceptes par le systeme, t :: a cette liste d'evenements augmentee du nouvel evene-ment a et [ ] la trace vide; le comporteevene-ment general du systeme est decrit par le pseudo-code suivant :
t r a c e := [ ] ;
Pour toujours, faire recevoir l'evenement a;
si main peut accepter t r a c e :: a alors t r a c e := t r a c e :: a ;
envoyer un evenement de sortie o tel que (trace, 6) G R; sinon
envoyer un message d'erreur;
Un evenement a est une instance d'une action. La signature d'une action a est decrite de la maniere suivante :
a(<7i :Ti,...,qn: Tn) : (qn+i '• Tn+i,..., qm : Tm)
ou qi,..., qn sont les parametres d'entree de types T i , . . . , Tn et qn+i, • • • ,qm sont les
para-metres de sortie de types Tn+i,... ,Tm. Les principes de la methode EB3, en particulier, la
syntaxe et la semantique des expressions de processus, sont definis de maniere exhaustive
dans [5].
2.2.3 Les expressions d e p r o c e s s u s d a n s la m e t h o d e EB
3En EB3 l'algebre de processus permet de definir l'ordonnancement des differents
evene-ments. Une expression de processus comporte dans sa definition des appels soit a une action definie dans le diagramme E-R soit a une autre expression de processus definie dans la speci-fication. Nous enumerons les differents operateurs utilises dans les expressions de processus, en denommant par membre l'appel a une autre expression de processus ou a une action.
• La sequence : elle est utilisee pour executer deux actions ou expressions de processus a la suite. Elle est representee par un point : membrei .
membrei-• Le choix : les actions ou expressions de processus n'ont pas a etre toutes realisees, mais
pour continuer l'une au moins doit etre achevee. Le choix est represente par une barre verticale : membrei |
membrei-• La composition parallele : les actions ou expressions de processus peuvent etre
rea-lisees dans n'importe quel ordre. S'il s'agit d'expressions de processus possedant des actions en commun, ces actions doivent etre synchronisers. La composition parallele est representee par deux barres paralleles : membrei \\
membre2-• L'entrelacement : il correspond a une composition parallele dans laquelle les deux
actions n'ont pas d'element commun. L'entrelacement est represente par trois barres verticales : membrei |||
membrei-• La garde : elle permet de conditionner l'execution d'une action a l'etat du systeme. Les gardes s'expriment de la maniere suivante : condition =>- membre. L'operande gauche d'une garde, ici appele condition, correspond a une formule logique faisant intervenir les attributs des differentes entites decrites dans le diagramme E-R.
Dans l'exemple de la bibliotheque, dont le diagramme E-R a ete donne a la figure 2.2, l'expression de processus main fait coexister les differents livres et membres, mais les syn-chronise sur leurs actions communes. La figure 2.4, presente le processus main associe a cet exemple. main <ll
III
III
mid bid €e
MemberlD : member(mld)* BookID book(b!d)*F I G . 2.4 - Processus main de l'exemple de la bibliotheque
Dans l'expression de processus main, member et book correspondent a de nouvelles ex-pressions de processus. Les figures 2.5 et 2.6 presentent leurs definitions.
member (mid) =
Register(mJd) • (
HI bid 6 BookID : loan(bId,mId)* ) •
Un register (mid)
F I G . 2.5 - Processus member de I'exemple de la bibliotheque
book(bId) = Acqu\re(bld) •
(
( | mid G MemberlD : loan(bId,mId))* ) •
Discard (bid)
F I G . 2.6 - Processus book de I'exemple de la bibliotheque
D'apres l'expression de processus main, member et book sont synchronisers sur l'execu-tion de loan. Cette nouvelle expression de processus est decrite a la figure 2.7.
loan(bId, mid) = Lend(bld, mid) •
Return(bid)
F I G . 2.7 - Processus loan de I'exemple de la bibliotheque
Cette specification ne limite pas le nombre d'emprunts par membre. Voyons maintenant comment limiter le nombre d'emprunts par membre a deux livres. Pour permettre cette limi-tation, une garde va etre mise en place dans Fune des expressions de processus precedentes. La garde va etre placee dans l'expression de processus loan. La figure 2.8 montre l'utilisation d'une garde dans I'exemple de la bibliotheque.
La syntaxe de l'expression conditionnelle correspondante a l'operande gauche de la garde sera etablie au chapitre 2.2.4.
loan(bId, mid) =
( member.nbLoansimld) < 1 =>• Ler\d(bld,mld) ) • Return (bid)
F I G . 2.8 - Processus loan utilisant une garde dans I'exemple de la bibliotheque
2.2.4 G a r d e s en EB
3Dans une expression de processus l'operateur de garde permet d'assujettir l'execution d'une expression de processus a une condition portant sur l'etat du systeme. Les differents termes peuvent etre obtenus a partir de constantes ou en interrogeant la base de donnees. Les types de base utilises dans la definition des gardes sont : les flottants, les chaines de caracteres, les estampilles (correspondant a une date et une heure donnees) et les booleens.
Constantes
Dans les gardes, l'utilisateur peut faire intervenir des constantes. Ces constantes peuvent etre des chaines de caracteres ou des nombres. Dans les gardes il n'y pas de distinction de type entre les nombres entiers et les nombres flottants. De plus l'utilisateur peut aussi faire intervenir des constantes permettant d'exprimer des dates.
Variables
Dans la figure 2.8 la garde mise en place pour limiter le nombre d'emprunts par membre, depend du membre. La valeur prise par la condition depend d'une variable exterieure, la formule logique definissant la garde peut done contenir des variables libres qui sont declarees dans l'entete des definitions de processus ou des expressions quantifiees.
Valeurs d'attributs non clef provenant de la base de donnees
La garde mise en place pour limiter le nombre d'emprunts par membre dans I'exemple de la bibliotheque doit lors de son evaluation connaitre la valeur de l'attribut nbloans, pour
une valeur de la clef member Key donnee. Dans la definition d'une garde, l'acces a la valeur d'un attribut attribut appartenant a une relation ou une entite concept pour une valeur key de cle s'ecrit concept.attribut(key).
On definit de la meme maniere la valeur prise par un role pour une valeur de clef don-nee. Dans l'exemple de la gestion de bibliotheque on peut par exemple utiliser F expression
book.borrower {book Key).
Ensemble des valeurs prises par un attribut
La definition d'une garde peut faire reference a Fensemble des valeurs prises par un attribut attribut, provenant de concept qui est soit une relation ou une entite. L'ensemble des valeurs prises par cet attribut est done note : concept.attribut. Dans l'exemple de la bibliotheque book.bookKey correspond a l'ensemble des valeurs prises par la clef de Pentite
book. Cette definition est etendue aux valeurs prises par un role role d'une entite entite. Par
exemple member.loans correspond a l'ensemble des livres empruntes par tous les membres de la bibliotheque.
Dans le cas de relations l'ensemble des valeurs prises par un role role pour une valeur de clef d'une entite entite donnee est entite.role[key). Par exemple member.loans (member Key) correspond aux emprunts d'un membre donne ayant comme valeur de clef member Key.
Ensemble defini par extension
Les ensembles dermis par extension peuvent servir a exprimer certaines conditions sur le systeme. Dans l'exemple de la bibliotheque on peut vouloir verifier que certains livres dont on connait le titre ne soient jamais acquis. L'ensemble contenant les elements element^... ,elementi sera defini de la maniere suivante : { element\ , . . . , elementi]
Operations arithmetiques
Elles permettent de manipuler les constantes arithmetiques, les variables et les valeurs d'attributs provenant de la base de donnees. Ces operations font intervenir deux termes. Elles correspondent aux operations de base :
• l'addition : termei + terme2
• la soustraction : termei — terme2 • la multiplication : termei x terme2
• la division : termei -i- terme2
L'operateur d'addition est surcharge : il est aussi utilise pour exprimer la concatenation entre deux chaines de caracteres intervenant dans 1'expression de la garde.
Operations ensemblistes
Elles comprennent les operateurs d'union et d'intersection entre deux ensembles : • l'union : ensemblei U ensemble?,
• l'intersection : ensemblei D ensemble?
Comparaisons arithmetiques
Ces tests permettent de comparer deux termes numeriques provenant de constantes, de variables ou etant la valeur d'un attribut de la base de donnees. Les differents operateurs de comparaisons sont :
• inferieur ou egal : termei < terme2
• superieur ou egal : termei > terme2
• egal : termei = terme2
L'exemple de la figure 2.8 montre une utilisation de ces operateurs pour limiter le nombre d'emprunts par membre. Ces operateurs de comparaison sont surcharges de maniere a etre utilises pour exprimer des comparaisons entre des estampilles ou des chaines de caracteres.
Dans le cas des estampilles, l'ordre chronologique est utilise. L'ordre lexicographique est utilise pour donner un sens aux comparaisons entre chaines de caracteres.
Tests d'appartenance d'un element a un ensemble
Dans l'exemple de la bibliotheque, on pourrait verifier que la personne fait bien partie des membres. On testerait l'appartenance de la valeur clef fournie par le membre a l'ensemble des valeurs prises par la clef de l'entite membre. Pour verifier qu'un element correspondant a une constante, une variable ou une valeur d'attribut appartient bien a un ensemble on utilise le test : element € ensemble.
Test d'inclusion ou d'egalite entre ensembles
Dans l'exemple de la bibliotheque, l'inclusion permettrait de verifier qu'un ensemble de livres dont on connait les titres est present : { titre\, titre?, titre3 } C book.title. Le
test d'inclusion permet de verifier qu'un ensemble est un sous-ensemble d'un autre alors que l'egalite verifie que les deux ensembles sont egaux.
• egalite : ensemblei = ensemble^
• inclusion : ensemblei C ensemble^
Conjonction, disjonction et negation
Ces operateurs seront utilises au sein d'une garde pour pouvoir exprimer plusieurs condi-tions. Dans le systeme de gestion de la bibliotheque, on pourra limiter le nombre d'emprunts a un seul livre par personne, pour les membres figurant sur une liste, et permettre aux autres d'emprunter toujours deux livres simultanement :
((mClef € {clef Membre^, clef Membre2}) A (member. nbLoans(mClef) = 0))
\j((->(mClef G {clef Membrei, clef Membre?})) A (member. nbLoans(mCle) < 1))
Les operateurs utilises sont :
• la disjonction : termei V terme2
• la negation : -> terme
Quantifications
Dans l'exemple de gestion d'une bibliotheque, lors de la fermeture de l'etablissement on voudrait verifier que tous les membres aient bien rendu leurs emprunts. Une fagon de faire est de verifier que pour chaque membre l'attribut nbLoans est nul. Ce test pourra s'ecrire a l'aide d'une quantification universelle : V x : member.member Key : member. nbloans(x) = 0. Les quantifications peuvent etre utilisees pour appliquer un predicat sur toutes les valeurs d'un ensemble.
• Quantificateur existentiel : 3 valeur : ensemble : predicat • Quantificateur universel : V valeur : ensemble : predicat
La semantique de ces expressions est donnee par les definitions suivantes. • 3 x : A : predicat(x) = 3 x : x € A A predicat(x)
• V x : A : predicat(x) = V x : x € A =>• predicat(x)
Grammaire utilisee pour la definition des gardes
Nous allons maintenant utiliser la notation BNF afin d'organiser les differents operateurs et termes precedents en une grammaire. Les conventions de notation sont les suivantes :
• Les mots et les operateurs du langage seront mis entre guillemets, par exemple : « + », « C », . . .
• Les elements non-terminaux seront ecrits en italique.
• Une definition de la grammaire sera donnee par e ::= elements, ou e est un element non-terminal de la grammaire et elements correspond a un ou plusieurs elements de la grammaire.
• e\e' correspond a l'element e ou e'
• (e) equivaut a e
• e* indique un nombre arbitraire positif ou nul d'occurrences de l'element e
• e+ correspond a un nombre arbitraire strictement positif d'occurrences de l'element e
La figure 2.9 presente la grammaire decrivant les gardes.
2.3 Limites de la plateforme APIS
Les environnements de travail utilises pour la creation d'applications web, simplifient l'acces a la base de donnees en proposant un ensemble d'API. La programmation des actions sous-jacentes a l'interface graphique reste a la charge du developpeur. Au contaire, lors de l'utilisation de la plateforme APIS ces actions sont automatiquement implementees a l'aide des differents modules composant cette plateforme.
Les expressions de processus decrivent revolution du systeme, c'est-a-dire la maniere dont les evenements se succedent au sein du systeme. EB3PAI utilise les expressions de processus
afin de valider ou de rejeter un evenement. Les actions dans les expressions de processus peuvent etre gardees. Pour que EB3PAI puisse evaluer les gardes, nous proposons de definir un
algorithme permettant leur implementation, et de modifier EB3PAI pour qu'il puisse utiliser
garde ::= quantification | expressionBooleenne | predicatAtomique | « ( » garde « ) » quantification ::=
(« V » | « 3 ») variable « : » ensemble « : » garde
expressionBooleenne ::= garde (« V » | « A ») garde | -i garde | « true » | « false » predicatAtomique ::— termeNumerique ( « < » | « > » | « > » | « < » | « = ») termeNumerique | terme « = » terme | ensembe (« C » | « = ») ensemble | terme « e » ensemble ensemble ::= identificateur « . » identificateur | identificateur « . » identificateur « ( »
(constante | variable \ valeurAttribut) (« , » constante | variable \ valeurAttribut)*« ) »
| « { » [ ierme ( « , » terme ) * ] « } » | ensemble (« U » | « D ») ensemble | « ( » ensemble « ) » terme ::= wa/eifr^4ttri6wt | variable | termeNumerique | constante | « ( » terme « ) »
termeNumerique ::= valeurAttribut | numerique | termeNumerique (« + » | « — » | « x » | « | « ( » termeNumerique (« + » | « — » | « x valeurAttribut ::= identificateur« . » identificateur« ( »
(constante \ variable | valeurAttribut) (« variable ::= identificateur constante ::= « " » string « " » | numerique numerique ::— •T- ») termeNumerique » | «-;-») termeNumerique « ) » , » constante \ variable
[ signe ] nombre+ [« . » nombre+ ] [« E » [ signe ] nombre+ ]
signe ::= « + » | « — » nombre ::= « 0 » | . . . | « 9 » identificateur ::= alpha caractere* string ::— alpha+ caractere ::= « A » | . . . | « Z » | « a » | . . . | « z » | « 0 » | . alpha ::= ( UNICODE ) + . | « 9 » valeurAttribut)*« ) »
Algorithme de traduction des gardes
vers du code executable
Dans ce chapitre nous presenters l'algorithme utilise pour traduire les gardes en code executable.
3.1 Principe de fonctionnement general
Pour la plateforme APIS, l'interoperabilite a oriente le choix du langage utilise pour implementer les gardes. Une des volontes des concepteurs d'APIS etait que cet outil puisse fonctionner sur le plus grand nombre de plateformes possible. Le choix s'est done oriente vers le langage Java. Celui-ci est compile dans un langage machine interprets par une machine virtuelle. Le code obtenu ne depend plus de la machine sur laquelle il est execute mais de la machine virtuelle. Le langage Java etant tres repandu, l'interpreteur est utilisable sur un grand nombre de systemes.
Dans l'implementation finale des gardes, il faut pouvoir interroger des bases de donnees. Le langage Java possede un ensemble de modules permettant la connexion avec des bases de donnees. Le plus connu et le plus utilise porte le nom JDBC. Ces modules sont eux aussi bien integres a la machine virtuelle et permettent d'etablir des connexions avec differents types
de SGBD (ex : MySQL, PostGRES, SQL, DB2, Oracle, SQLServer ...). Le choix du couple Java-SQL comme langage d'implementation parait etre le plus judicieux pour atteindre le meilleur niveau d'interoperabilite.
Comme la garde possede dans sa definition des references a des attributs du modele E-R, il faut pouvoir interroger la base de donnees. Les donnees ainsi obtenues doivent etre traitees arm de renvoyer la valeur de la garde. Cette separation des taches d'interrogation et de traitement est facilitee par l'utilisation du couple Java-SQL. En effet, le rapatriement des donnees se fera a l'aide du langage SQL tandis que le traitement de ces donnees se fera a l'aide du langage Java.
Pour realiser de maniere automatique l'implementation des gardes a partir de leurs defi-nitions, nous etablissons des regies qui permettent de traduire les operateurs definis dans la grammaire au chapitre 2.2.4. Ces regies sont scindees en deux categories, d'une part celles qui creent du code SQL et d'autre part celles qui creent du code Java.
Pour pouvoir utiliser ces regies de traduction, le module EB3GG prend en entree les
de-finitions des gardes. Tout d'abord, l'outil realise une analyse lexicale et syntaxique de ces definitions et construit un arbre syntaxique les representant. Cet arbre sera alors parcouru pour proceder a l'analyse semantique des definitions de gardes et pour obtenir une representa-tion objet de ces definirepresenta-tions. Cette representarepresenta-tion objet subit ensuite trois etapes successives de maniere a implementer les gardes. D'abord, le module procede a une normalisation de certains operateurs presents dans la definition des gardes. Une transformation de la repre-sentation objet est ensuite realisee. Un sous-ensemble de cette reprerepre-sentation est transforme en objet correspondant a une representation de requete d'interrogation de bases de donnees. Cette etape equivaut a l'application des regies de traduction en SQL. Ensuite le code execu-table peut etre obtenu. Pour arriver a ce resultat la structure est parcourue a nouveau dans sa totalite. Lors de cette etape les elements qui n'ont pas encore subi de transformation sont traduits a l'aide des regies de traduction en Java. Les elements correspondant aux requetes obtenues a l'aide des regies de traduction en SQL sont transformed en requetes SQL.
