Génération de code à partir d une spécification B : Application aux bases de données

Transcription

1 Génération de code à partir d une spécification B : Application aux bases de données Amel Mammar * Régine Laleau ** Université du Luxembourg, LACL, Université Paris 12 SE2C, 6 rue Richard Courdenhove-Kalergi IUT Fontainebleau, Route forestière L-1359 Luxembourg-Kirchberg, Hurtault, Fontainebleau [email protected] [email protected] RÉSUMÉ. Le travail décrit dans cet rapport entre dans le cadre de la conception d une démarche complète et outillée de développement d applications bases de données sûres. Le point de départ de notre démarche est une spécification B traduisant un ensemble de diagrammes UML dotés d une sémantique formelle dédiée aux systèmes d information. Cette spécification est ensuite raffinée par des règles automatiques et prouvées. Ce raffinement a pour but de rendre la spécification initiale proche d une implémentation relationnelle, de telle sorte que la dernière phase de traduction devienne intuitive et naturelle. La contribution principale de ce rapport est de fournir une démarche systématique de traduction des composants terminaux B en une implémentation relationnelle. Cette traduction concerne deux aspects complémentaires : les données concrètes correspondant au schéma de la base de données, et les opérations concrètes B correspondant aux différents traitements. Contrairement à un schéma de bases de données qui peut être entièrement défini en SQL, les traitements nécessitent l utilisation d un langage hôte offrant des structures de contrôle équivalentes aux constructeurs de substitutions B. ABSTRACT. The work described in this report aims at defining a complete and tool supported approach for the development of safe databases applications. The starting point of our approach is a B specification translating a set of UML diagrams for which a formal semantics, dedicated for information systems, is assigned. This specification is then refined by formal and proved rules. This refinement process aims at making the initial specification close to a relational implementation such that the last translation phase becomes intuitive and straightforward. The main contribution of this report is to provide a systematic approach translating the terminal B components into a relational implementation. This translation concerns two complementary aspects : the data corresponding to the database schema, and the B operations corresponding to the system functionalities. Contrary to the database schema which can be completely defined in SQL, functionalities require the use of a programming language offering control structures which should be equivalent to the B substitution constructors. MOTS-CLÉS : Aide au développement, bases de données, raffinement, codage. KEYWORDS: Development assistance, databases, refinement, coding. 2 e soumission à Technique et science informatiques, le 24 mars 2005.

2 2 2 e soumission à Technique et science informatiques. 1. Introduction Les applications bases de données sont caractérisées par des transactions 1 s exprimant à l aide de structures de contrôle relativement simples. Cependant, ces traitements manipulent des quantités importantes de données interdépendantes et fortement liées. Dans ce type d applications, la difficulté pour les concepteurs réside essentiellement dans l écriture de programmes qui respecteraient l intégrité de l ensemble des données. Bien que ce type d applications ne soit pas réellement critiques (pas de risque humain), ces dernières sont de plus en plus utilisées dans des domaines à enjeux économiques importants, comme le e-business, les systèmes financiers et les cartes à puces, et nécessitant donc un certain degré de fiabilité. Les méthodes classiques de conception d applications bases de données, basées essentiellement sur des notations graphiques, permettent d avoir une vue synthétique du système qui facilite la communication entre les différents acteurs. Cependant, les notations graphiques (comme UML) ne permettent pas d exprimer la totalité des propriétés d un système. De plus, leur manque de sémantique précise rend le raisonnement sur les spécifications obtenues et la génération d implémentations (même partielles) difficiles à mettre en œuvre. Le cadre général de nos travaux de recherche, menés au sein du laboratoire CE- DRIC du CNAM, porte sur la définition d une approche formelle et outillée de développement d applications bases de données sûres. L approche que nous proposons comporte trois phases complémentaires : 1. traduction de diagrammes UML en notations B, 2. raffinement des spécifications B obtenues en une implémentation relationnelle, 3. génération de code JAVA/SQL à partir de l implémentation B. Dans ce rapport, nous mettons l accent sur la description des règles de génération de code JAVA à partir d une implémentation B obtenue suite aux deux premières étapes décrites dans nos publications antérieures [LAL 00b, MAM 01]. Le but de ce rapport est de montrer la faisabilité de la génération, en JAVA/SQL, du code d une transaction base de données développée par raffinement B. La suite de ce rapport est structurée comme suit. La section suivante donne une brève présentation du langage B et du modèle relationnel, et présente les caractéristiques du sous-langage B décrivant une implémentation relationnelle. La section 4 illustre, à travers une étude de cas, la génération de spécifications B à partir des diagrammes UML ainsi que le processus de raffinement des données. Le processus d implémentation des transactions, obtenues à la phase précédente, est décrit à la section 5. Nous décrivons, dans la section 6, quelques règles de traduction de cette implémentation en code exécutable JAVA/SQL. La section 7 présente des travaux similaires à notre approche. Nous terminons par une conclusion et des perspectives. 2. Le langage B pour le développement d applications bases de données Dans cette section, nous donnons un bref aperçu de la méthode B et du modèle relationnel nécessaire à la compréhension de ce rapport. Nous décrivons également 1. Le terme "transaction" désigne l exécution ininterrompue de plusieurs opérations élémentaires.

3 De B vers JAVA/SQL 3 les structures de données et de contrôle qui définissent notre dernier niveau de raffinement La méthode B Conçue par J-R. Abrial, la méthode B [ABR 96] est une méthode formelle de développement d applications sûres. Elle couvre l ensemble des phases de conception d un projet : de la spécification abstraite jusqu à la génération du code associé. La notion de base du langage B est la machine abstraite qui décrit un système à travers un ensemble de variables dites d états. Le typage et les contraintes régissant ces variables, écrits dans une variante de la théorie des ensembles de Zermalo-Frankel (ZF), sont exprimés dans la clause INVARIANT de la machine. La partie dynamique du système est spécifiée par un ensemble d opérations B. Les opérations sont décrites dans le langage des substitutions généralisées de Disjkstra. La substitution de base est l affectation d une valeur à une variable. La généralisation de ce langage permet de définir des substitutions plus élaborées : substitution non déterministe, substitution préconditionnée, etc. Une substitution préconditionnée est de la forme : PRE p THEN s, p étant un prédicat et s une substitution. Si p est vérifié alors la substitution s est exécutée correctement, sinon s échoue : le résultat de l exécution de la substitution s devient imprévisible. La méthode B propose plusieurs clauses d architecture permettant ainsi une spécification incrémentale. Au niveau le plus abstrait, le lien le plus utilisé est INCLUDES. Une machine A peut être incluse au plus une seule fois dans une machine C : les variables de A peuvent être lues dans C, la mise à jour de ces variables n est possible qu à travers l appel des opérations de A. Cette restriction permet une séparation des preuves associées aux deux machines. Le raffinement est le processus de transformation de spécifications abstraites en spécifications plus concrètes. En B, on distingue deux types de raffinement : Raffinement algorithmique : c est la transformation d une substitution abstraite S en une substitution moins abstraite S (exemple : remplacement d une substitution simultanée par une substitution séquentielle, élimination des préconditions). Raffinement de données : c est le remplacement d une donnée abstraite D par une donnée concrète D (exemple : raffinement d un ensemble par un tableau). Dans ce cas, un prédicat J, appelé invariant de collage, est à préciser. Cet invariant permet d établir le lien entre les données D et D. L invariant de collage J est spécifié dans la clause INVARIANT du composant raffinant. Ces deux types de raffinement ne sont pas exclusifs : ils peuvent être opérés dans la même étape de raffinement. Il est évident que tout raffinement de données entraîne un raffinement algorithmique. En effet, les substitutions ne travaillant plus sur le même espace de variables, celles-ci doivent être réécrites (raffinées) en fonction du nouvel espace des variables. Le dernier niveau de raffinement d une machine abstraite est appelé implémentation. Les structures de données et de contrôle B utilisés dans la description d une implémentation doivent être supportées par le langage de programmation cible choisi. La traduction de cette implémentation vers le langage cible devient donc très naturelle et potentiellement automatisable. Actuellement, plusieurs générateurs automatiques de code permettent la traduction en ADA, C et C++ de l implémentation

4 4 2 e soumission à Technique et science informatiques. d une machine abstraite décrite dans le langage B0 2. Une implémentation peut importer (liens IMPORTS) plusieurs machines abstraites afin d implémenter ses propres données et opérations. Seules les opérations de la machine importée sont accessibles, les variables abstraites ne le sont pas. La méthode B permet une validation complète des phases du développement d un projet. En effet, des obligations de preuves sont générées pour la phase de spécification et pour chaque étape de raffinement. Ces preuves permettent d assurer la cohérence de la spécification abstraite et la conformité du code final vis-à-vis de la spécification initiale (modulo la phase de codage faite en dehors de la méthode B). Une description des principales substitutions B est donnée en annexe. La sémantique des différents éléments B utilisés dans ce rapport sera donnée au fur à mesure de leurs introductions Le modèle relationnel Le modèle relationnel a été introduit par Codd [COD 70]. Il permet de décrire le monde réel en terme de relations que nous appelons ici tables pour ne pas confondre avec le concept de relation du langage B. La définition d une table comprend deux parties complémentaires : l intention et l extension. L intention appelée aussi schéma, définit son type i.e les attributs qui la constituent et leurs domaines respectifs. L extension d une table désigne l ensemble des tuples existants à un instant donné. Chaque tuple de cette extension représente une valeur du produit cartésien des domaines des attributs de la table. Dans ce rapport, nous utilisons la norme 92 du langage SQL [MEL 93]. Des contraintes d intégrité peuvent être définies aussi bien sur les attributs d une table que sur un ensemble de tables. Une contrainte, introduite par le mot clé CHECK, définit un prédicat devant être vérifié par chaque extension possible de(s) la table(s) mise(s) en œuvre. Les contraintes pouvant être définies sur les attributs d une table sont les suivantes : NOT NULL :définie sur un attribut, cette contrainte permet de spécifier que l attribut concerné doit être valué pour chaque tuple de la table. UNIQUE : définie sur un (ou un ensemble d ) attribut(s), cette contrainte permet de spécifier que la valeur de (ou des) l attribut(s) est unique dans toute extension possible de la table. Clé :définie sur un (ou un ensemble d ) attribut(s), cette contrainte permet de spécifier une clé possible d une table donnée. Une table possède au moins une clé désignée comme primaire (PRIMARY KEY). Les autres clés candidates sont spécifiées par les deux contraintes NOT NULL et UNIQUE. Contrainte référentielle :définie sur un (ou un ensemble d ) attribut(s) R 1 d une table T 1 vers un (ou un ensemble d ) attribut(s) R 2 clé d une table T 2, cette contrainte spécifie que l ensemble des valeurs de R 1 est inclus dans l ensemble des valeurs de R B0 désigne le sous-langage de B utilisé pour la description d une implémentation. Il comporte essentiellement les types de données et les structures de contrôle supportées par la majorité des langages de programmation comme C, ADA, etc.

5 De B vers JAVA/SQL 5 Le modèle relationnel est un modèle orienté valeurs : chaque tuple est identifié par la valeur d un ou plusieurs attributs qui constituent la clé de la table Caractérisation d une implémentation B0/SQL Dans cette sous-section, nous décrivons les structures de données et de contrôle (instructions B) que nous admettons à notre dernier niveau de raffinement. De manière générale, les structures de données correspondent à l expression en B des concepts relationnels. Les structures de contrôle correspondent à celles supportées soit par SQL ou par le langage JAVA choisi comme langage hôte Structures de données : expression des concepts relationnels en B Le but de tout processus de raffinement est l obtention d un niveau de spécification directement traduisible dans le langage d implémentation choisi. Pour cela, une modélisation B des concepts relationnels est nécessaire. C est elle qui détermine le dernier niveau du processus de raffinement : le processus de raffinement s arrête quand les variables raffinées correspondent à la spécification B des concepts relationnels. Comme mentionné précédemment, la structure de base du modèle relationnel est la table définie formellement comme un sous ensemble du produit cartésien d un ensemble de types nommés appelés domaines ou attributs. Cette définition correspond précisément à la notion d "enregistrement" en B permettant de regrouper plusieurs informations indissociables et nommées en une seule entité. Chaque champ de cet enregistrement correspond à l un des attributs de la table. L extension (le contenu) d une table désigne un ensemble d enregistrements. Afin d avoir un développement structuré, nous avons choisi d exprimer la spécification de chaque table dans une machine abstraite séparée. Une telle machine, appelée machine SQL dans la suite de ce rapport, définit une variable abstraite représentant l extension de la table, et un ensemble d opérations B correspondant aux différentes requêtes SQL comme l insertion d un tuple, la suppression d un tuple etc.. Une table A, dont les attributs sont att 1,...,att n de types T 1,...,T n respectivement et de clé att 1, est spécifiée en B par une machine abstraite Rel A définie comme suit 3,4, 5 : MACHINE Rel A VARIABLES Table A INVARIANT Table A struct(att 1 : T 1,...,att n : T n ) (x, y).(x att 1 = y att 1 x = y) INITIALISATION Table A := OPERATIONS /*Ajout d un tuple : insert into Table A values (val 1,...,val n )*/ InsertA(val 1,...,val n ) = PRE val 1 T 1... val n T n THEN 3. rec(x 1,..., x n) désigne, en B, un enregistrement dont les valeurs des champs sont x 1,...,x n. 4. x y : dénote la valeur du champ y pour l enregistrement x. 5. ANY x WHERE P THEN S désigne l exécution de la substitution S pour n importe quelle valeur de x satisfaisant le prédicat P.

6 6 2 e soumission à Technique et science informatiques. Table A := Table A {rec(val 1,...,val n )} ; /*suppression d un tuple désigné par sa clé : delete from Table A where att 1 = val*/ DeleteA(val) = PRE val T 1 THEN ANY xx WHERE xx Table A xx Att 1 = val THEN Table A := Table A {xx} ; Structures de contrôle Comme nous le verrons dans la suite de ce rapport, le dernier niveau de notre processus de raffinement est constitué principalement d un ensemble de machines SQL importées par un composant implémentation. Ces machines SQL sont directement traduisibles en SQL. Notons que SQL étant un langage assertionnel ensembliste, il supporte une certaine forme d indéterminisme comme le choix arbitraire d un élément ou d un ensemble qui vérifie un prédicat. Ceci nous permet d avoir dans les opérations B de ces machines (cf exemple du "DeleteA" ci-dessus) des substitutions indéterministes (ANY X WHERE P THEN S ). En revanche, les substitutions de notre composant implémentation sont un sous-ensemble de celles admises en B0. Nous admettons exclusivement les instructions suivantes : If-Then-Else, Affectation, Appel d opérations, Variable locale (VAR X IN S ), Séquence et Tant que (boucle). Ces instructions sont suffisantes pour l expression de n importe quelle transaction base de données. 3. Vue d ensemble de l approche L approche que nous proposons comporte les étapes suivantes (voir figure 1) : 1) Modélisation UML : les données et les traitements du système sont représentés par des diagrammes UML spécialisés pour la description des systèmes d information [LAL 02]. Les données et les opérations de base (comme l insertion, suppression d objets, etc) sont naturellement décrites par un diagramme de classes. Pour les transactions, nous avons considéré les diagrammes d états/transitions et de collaborations. 2) Génération de spécifications B : à partir des diagrammes UML élaborés à la phase précédente, des spécifications B sont automatiquement générées. Si les spécifications traduisant les classes sont prouvées automatiquement par le prouveur de l AtelierB [DIG 96], la preuve des opérations supprimant un ensemble de liens d une association nécessite l ajout de règles utilisateur validées à leur tour par l AtelierB. Plus de détails peuvent être trouvés dans [MAM 02]. 3) Processus de raffinement : les spécifications abstraites prouvées sont successivement raffinées jusqu à l obtention d une implémentation relationnelle. Le processus de raffinement que nous avons défini est composé de deux phases successives et complémentaires : raffinement des données/opérations de base et raffinement des transactions. La première phase, entièrement automatique, s appuie sur l algorithme décrit

7 De B vers JAVA/SQL 7 Modélisation UML: Spécification UML pour les SI A * B * Traduction Génération de spécifications B Preuve Spécification abstraite B d un SI Processus de raffinement Raffinement des données et des opérations de base Données et opérations de base raffinées Raffinement des transactions Preuve Spécification concrèted une implémentationrelationnelle en B Traduction Preuve Production du code JAVA/SQL - Schémades relations en SQL - Classes JAVA/SQL représentant les opérations de base surles tables - Code des transactions en JAVA/SQL Plusieursétapessuccessives de raffinement Figure 1. Des spécifications UML à une implémentation relationnelle dans [Bat 92]. Cette phase est formalisée par un ensemble de règles de raffinement décrites en détail dans [LAL 00a]. Plusieurs niveaux de raffinement ont été définis permettant ainsi une meilleure gestion de la complexité des preuves de correction associées. À l issue de cette première phase, une seconde phase, semi automatique, raffine les transactions. Cette phase est décrite dans la section 5. À chaque phase de ce processus de raffinement, on prouve que la spécification obtenue respecte les propriétés de la spécification qu elle raffine : de proche en proche, on établit la conformité de l implémentation B vis-à-vis de la spécification abstraite initiale. 4) Production du code JAVA/SQL : cette étape produit le code correspondant à la spécification du dernier niveau de raffinement. Cette phase de codage permet de définir, d une part, le schéma de la base de données et les requêtes SQL de base associées (insertion, suppression d un tuple, etc), et d autre part, le code JAVA/SQL correspondant aux transactions. Dans ce rapport, nous mettons plus l accent sur l implémentation des transactions ainsi que sur la phase de production du code JAVA/SQL. 4. Élaboration et raffinement de la spécification B : illustration par l exemple L objet de cette section n est pas de décrire exhaustivement la génération de spécifications B à partir des diagrammes UML et leur raffinement successif, mais plutôt de caractériser la forme générique et standard des spécifications obtenues tant au niveau abstrait qu au niveau concret. Ces caractéristiques sont très importantes dans le sens où elles permettent la définition d une approche systématique de développement

8 8 2 e soumission à Technique et science informatiques. formel. Dans ce qui suit, nous présentons les principaux résultats illustrés sur un cas d étude décrit ci-après. La spécification B et le code JAVA/SQL complet de cette étude de cas sont donnés en annexes Présentation du cas d étude Le système que nous considérons concerne la gestion d un club vidéo simplifié de prêts d un ensemble de cassettes. Il s agit avant tout d un exemple didactique permettant d illustrer l approche développée. Chaque cassette décrite par un titre (Titre) est caractérisée par le nombre de copies disponibles (NbLibre). Plusieurs cassettes peuvent avoir le même titre.une copie de cassette appartient à une seule boutique identifiée par un numéro (NumBo) et caractérisée par une adresse (AdresBo). Un client identifié par un numéro (NumCl) est décrit par un nom (NomCl). Un client peut emprunter plusieurs cassettes, de même, une cassette peut être empruntée par plusieurs clients dans la limite du nombre de copies disponibles. Le prêt d une cassette par un client est caractérisé par une date (DateE) et un statut (Statut). La structure des données de ce système est décrite par la figure 2. Le statut d un nouvel emprunt dépend de la disponibilité de la cassette sur laquelle porte l emprunt. Si au moins une copie de cette cassette est disponible, l emprunt est enregistré avec un statut en cours (Statut=Ok), sinon en attente (Statut= Att). Figure 2. Diagramme de classes du club vidéo 4.2. Génération et caractéristiques des spécifications B Les caractéristiques principales des spécifications B que nous obtenons par traduction des diagrammes UML sont leur structure et leur forme génériques. Ces spécifications sont organisées en deux niveaux : interne et externe. Ces deux niveaux sont détaillés ci-après Niveau interne Le niveau interne est dérivé à partir du diagramme de classes UML. Il contient les variables définissant l état du système ainsi qu un ensemble d opérations de base agissant sur ces variables. Ce niveau est interne dans le sens où les variables et les

9 De B vers JAVA/SQL 9 opérations définies à ce niveau ne sont pas visibles pour l utilisateur, c.à.d, ne font pas partie de l interface de la spécification. La spécification B de ce niveau interne est construite comme suit. Pour chaque classe A, ondéfinit un ensemble abstrait S A de toutes les instances possibles de A et une variable v A représentant l ensemble des instances existantes de A. Chaque attribut de la classe est représenté par une variable v Att qui est une relation binaire entre v A et le type T Att de l attribut. En fonction de la multiplicité de l attribut, cette relation peut devenir une fonction, une injection, etc. On suppose que les types UML de base correspondent aux types de base B. Une association Ass entre deux classes X et Y est représentée par une variable v Ass définie comme une relation entre les instances existantes des deux classes v X et v Y. Comme pour les attributs, le type de la relation dépend de la multiplicité de l association. Un attribut d association est formalisé de la même manière que celui d une classe. Par exemple, les classes Cassette, Boutique et les associations Emprunt et Appartient sont traduites par : SETS Cassette, Client, STATUT = {Ok, Att},... VARIABLES cassette, Titre, NbLibre, boutique, NumBo,client, Appartient, Emprunt... INVARIANT cassette Cassette Titre cassette STRING NbLibre cassette NAT NumBo boutique NAT Appartient cassette boutique Emprunt cassette client... Les opérations de base sont des opérations indépendantes des traitements à réaliser ultérieurement. Elles sont générées automatiquement à partir du diagramme de classes. Ces opérations permettent l insertion ou suppression des objets (resp. liens) d une classe (resp. association) et la modification de la valeur des attributs. Comme exemple d opérations de base, considérons les opérations d ajout d une nouvelle cassette, d un nouvel emprunt et la mise à jour du nombre de cassettes disponibles exprimées en B par : BasicAjoutCassette(ca, ti, nb, bo) = PRE ca Cassette-cassette ti STRING nb NAT bo boutique THEN cassette := cassette {ca} Titre := Titre {ca ti} NbLibre := NbLibre {ca nb} Appartient := Appartient {ca bo} BasicChangeNbLibre(ca,nb) = PRE ca cassette nb NAT THEN NbLibre(ca) :=nb BasicAjoutEmprunt(ca, cl, da,st) = PRE ca Cassette cl Client ca cl / Emprunt da NAT st STATUT THEN Emprunt := Emprunt {ca cl} Date E := Date E {ca cl da}

10 10 2 e soumission à Technique et science informatiques. Statut := Statut {ca cl st} Niveau externe Le niveau externe contient la spécification B des transactions représentant les fonctionnalités du système décrites par les diagrammes états/transitions et de collaborations. Chaque transaction spécifie la façon dont sont utilisées les opérations de base des différentes classes et associations pour l accomplissement de la fonctionnalité considérée. Elle est traduite en une opération B. Contrairement au niveau interne, les opérations du niveau externe sont accessibles à l utilisateur. Notons néanmoins qu une opération du niveau interne peut être rendue accessible à l utilisateur [NGU 98]. Dans ce rapport, nous nous intéressons à la transaction LocationCassette qui permet à un client donné de louer, dans une boutique d adresse adbo, une cassette désignée par son titre. Deux cas sont à distinguer. Le prêt n est accordé (sinon resultat="erreur") que si le client est en règle, c.à.d, qu il n a pas de location en retard (plus de 90 jours de retard). Dans ce cas, on sélectionne une cassette quelconque ca ayant les caractéristiques souhaitées, puis, en fonction du nombre de copies disponibles de cette cassette on ajoute l emprunt avec un statut en cours (resultat="succes") ou en attente(resultat="att"). Si une copie de la cassette est disponible, on décrémente la valeur de l attribut NbLibre. En B, cette transaction est spécifiée comme suit (on vérifie, en précondition, qu une cassette ayant les propriétés désirées (Titre[Appartient 1 [AdresBo 1 [{adbo}]]]) et non déjà empruntée par cl existe bien(titre[emprunt 1 [{cl}]]), DateCourante est une variable définie dans une machine incluse par la machine abstraite traduisant les diagrammes UML) : resultat LocationCassette(cl, adbo, ti) = PRE cl client adbo ran(adresbo) ti Titre[Appartient 1 [AdresBo 1 [{adbo}]]] Titre[Emprunt 1 [{cl}]] THEN IF ( ca.(ca Emprunt 1 [{cl}] DateCourante DateE(ca, cl) 90)) THEN ANY ca WHERE ca cassette AdresBo(Appartient(ca)) = adbo Titre(ca) =ti THEN IF NbLibre(ca) > 0 THEN BasicAjoutEmprunt(ca, cl, DateCourante, Ok) resultat :="succes" ELSE BasicAjoutEmprunt(ca, cl, DateCourante, Att) resultat :="att" IF NbLibre(ca) > 0 THEN BasicChangeNbLibre(ca, NbLibre(ca) 1) ELSE resultat :="erreur" Notons que la spécification B est normalement structurée en un ensemble de machines. De manière générale, une machine abstraite est associée à chaque classe ou association UML. Ces machines sont ensuite incluses (lien INCLUDES de B) dans une machine dans laquelle sont spécifiées les opérations correspondant aux transactions. Dû aux contraintes actuelles de B, le processus de raffinement que nous avons

11 De B vers JAVA/SQL 11 défini nécessite que toute la spécification B soit contenue dans une seule machine. Pour cela, nous déclarons les opérations de base comme des définitions, les opérations traduisant les transactions comme les opérations de la machine. Plus d informations sur la construction d une telle machine unique peuvent être trouvées dans [MAM 02] Processus de raffinement des données Le processus de raffinement des données est complètement automatique et est représenté par un ensemble de règles formelles basées sur le pattern-matching. Il est construit à partir de l algorithme classique de traduction d un modèle conceptuel de données en modèle relationnel [Bat 92]. Une description plus complète et formelle de ces règles ainsi que la preuve de complétude et de terminaison de ce processus sont données dans [MAM 02, LAL 00a]. Le but d un tel processus de raffinement est l obtention d un niveau d abstraction correspondant à la formalisation B des concepts du modèle relationnel. Dans ce rapport, nous nous restreignons à la description des principales étapes : 1) Identification des objets 2) Élimination des associations monovaluées 3) Élimination des autres associations 4) Passage d un modèle fonctionnel à un modèle ensembliste 5) Implémentation des données et opérations de base Les sous-sections ci-après expliquent chacune de ces étapes et l illustrent sur le cas d étude du club vidéo Identification des objets Un attribut clé (fonction injective en B) est exhibé pour chaque classe du diagramme UML. Si une des classes ne possède pas initialement de clés, un attribut clé est rajouté. Cette étape est nécessaire car dans le modèle relationnel, chaque table doit avoir une clé. La classe Cassette n ayant pas de clé (pas de fonction injective B), cette étape rajoute une fonction injective NumCa de type NAT définie comme suit : NumCa cassette NAT Afin de maintenir cet invariant, l opération BasicAjoutCassette est raffinée en ajoutant à son corps la substitution suivante qui met à jour la variable ajoutée : ANY nu WHERE nu NAT ran(numca) THEN NumCa := NumCa {ca nu} Élimination des associations monovaluées Une association sans attributs dont l un des rôles est de multiplicité 1 est remplacée par un attribut additionnel à la classe opposée au rôle monovalué. Cet attribut est lié par une contrainte d intégrité à la clé de la classe associée au rôle monovalué. Intuitivement, cette règle revient à remplacer chaque objet de la classe associée au

12 12 2 e soumission à Technique et science informatiques. rôle monovalué par la valeur de sa clé. En B, cela revient à remplacer la fonction Appartient par une fonction AppartientMig définie par l invariant de collage suivant : AppartientMig cassette NAT AppartientMig =(Appartient ;NumBo) Par conséquent, l opération BasicAjoutCassette est raffinée en remplaçant la substitution sur la variable Appartient par (AppartientMig := AppartientMig {ca NumBo(bo)}) Élimination des autres associations Une association avec attributs ou multivaluée est transformée en une classe ayant, en plus de ses propres attributs, deux attributs supplémentaires (un par classe) liés par des contraintes référentielles aux clés des deux classes concernées par l association. L application de cette règle sur la relation Emprunt, qui traduit une association, rajoute deux variables EmpruntCa et EmpruntCl de type NAT (type des clés NumCa et NumCl). Le couple formé par ces deux attributs est une clé de la classe Emprunt. Ces variables sont donc définies par : EmpruntCa = Emprunt 6 (prj 7 1 (cassette, client) ;NumCa) EmpruntCl = Emprunt (prj 8 2 (cassette, client) ;NumCl) EmpruntCa 9 EmpruntCl Emprunt NAT NAT Suite à ce raffinement de données, l opération BasicAjoutEmprunt est raffinée en ajoutant la substitution suivante qui met à jour les variables rajoutées : EmpruntCa := EmpruntCa {ca cl NumCa(ca)} EmpruntCl := EmpruntCl {ca cl NumCl(cl)} Passage d un modèle fonctionnel à un modèle ensembliste Le but de cette étape est la définition des structures des différentes tables. L idée intuitive est de rassembler sous le nom d une variable (table) les caractéristiques concernant une même classe. Cette variable sera par la suite traduite par une table SQL. Par cette règle, les fonctions NumCa, Titre, NbLibre et AppartientMig, définies sur la variable cassette, sont regroupées sous l unique variable T Cassette définie par l invariant de collage suivant : T Cassette cassette NAT STRING NAT NAT T Cassette = NumCa Titre NbLibre AppartientMig Selon le même principe, les substitutions abstraites qui portaient sur les variables NumCa, Titre, NbLibre et AppartientMig sont remplacées par une seule substitution concrète agissant sur la variable T Cassette. L opération BasicAjoutCassette est raffinée par : BasicAjoutCassette(ca, ti, nb, bo) = 6. X f = {x y x y f x / X} 7. prj 1(X, Y) ={(x y) x x X y Y} 8. prj 2(X, Y) ={(x y) y x X y Y} 9. f g = {x (y z) x y f x z g}

13 De B vers JAVA/SQL 13 BEGIN ANY nu WHERE nu NAT ran(numca) THEN cassette := cassette {ca} T Cassette := T Cassette {ca (nu ti nb NumBo(bo))} Implémentation des données et opérations de base Cette étape permet d implémenter les différentes tables (produits directs) définies à la section précédente. On va utiliser les machines SQL définies à la section Pour chaque produit direct T C, une machine SQL est importée. L implémentation des variables abstraites par les variables des machines importées est basée sur l identification de chaque objet à la valeur de sa clé. L implémentation de la variable T C par Table C est exprimée par un invariant de collage qui associe chaque tuple de T C àun enregistrement unique de Table C et vice-versa. Cet invariant de collage définit une relation 1-1 entre les variables abstraites et les variables concrètes et vice-versa. Chaque opération de base op 1 est implémentée par son équivalente définie dans la machine SQL. Plus de détails peuvent être trouvés dans [MAM 01]. Par exemple, la variable T Cassette est implémentée par la variable Table Cassette définie dans la machine SQL Cassette Rel importée par notre implémentation. La machine Cassette Rel spécifie les opérations d ajout d une cassette ainsi que la mise à jour du nombre de cassettes disponibles. Dans ce rapport, nous donnons à ces opérations des noms différents de celles des opérations de base pour pouvoir les distinguer dans la suite. La machine Cassette Rel est décrite comme suit : Machine Cassette Rel Variables Table Cassette INVARIANT Table Cassette struct(numca : NAT, Titre : String, NbLibre : NAT, Appartient : NAT) Operations InsertionCassette(nu, ti, nb, bo) = /*Ajout d une nouvelle cassette */ PRE nu NAT ti STRING nb NAT bo NAT THEN Table Cassette := Table Cassette {rec(nu, ti, nb, bo)} ; UpdateNbLibre(ca,nb) = /*Mise à jour du nombre de copies disponibles d une cassette*/ PRE ca NAT nb NAT THEN ANY xx WHERE xx Table Cassette xx NumCa = ca THEN Table Cassette := Table Cassette {xx} {rec(xx NumCa, xx Titre, nb, xx Appartient)} 5. Implémentation des transactions Les opérations B représentant les transactions restent invariables tout au long du processus de raffinement des données présenté ci-dessus, modulo la réécriture des va-

14 14 2 e soumission à Technique et science informatiques. riables abstraites en fonction des variables concrètes. Les transactions que nous considérons sont de la forme (les crochets désignent des parties optionnelles) : Trans =[X ]Trans(param 1,...,param n ) = BEGIN S où la syntaxe de la substitution S est définie par (S i est de la même forme que S): S ::= BasicOperation(param 1,...,param k ) S 1 S 2 IF Pred THEN S 3 ELSE S 4 ANY Y WHERE Pred THEN S 5 [X :=...] Implémenter la transaction Trans revient à implémenter la substitution S. L implémentation d une substitution S doit répondre à trois besoins : 1) remplacer les références aux variables abstraites par les variables des machines importées. En effet, les paramètres effectifs d appel des opérations utilisées par les transactions, mais également les prédicats des substitutions IF, peuvent faire référence aux variables abstraites qui ont été remplacées par des variables concrètes définies dans les machines importées. La transaction LocationCassette, par exemple, fait référence aux variables abstraites Emprunt et DateE pour l expression de la condition de prêt, et utilise la variable abstraite NbLibre comme paramètre effectif d appel de l opération BasicChangeNbLibre. Or les variables abstraites définies dans les machines SQL ne sont visibles par l implémentation qu à travers des opérations de lecture définies dans les machines SQL ou dans une machine incluant ces dernières. Nous devons donc spécifier pour chaque prédicat (resp. paramètre effectif) une opération renvoyant sa valeur. Par abus de langage, nous appelons ces opérations "opérations implémentant les prédicats et les paramètres effectifs". 2) raffiner les constructeurs non admis en B0 par d autres constructeurs admis soit en B0 ou dans le langage cible JAVA/SQL. 3) remplacer, dans le corps de chaque transaction, les appels aux opérations de base par des appels aux opérations des machines importées. En effet, comme chaque opération de base est implémentée par une opération d une machine importée, on a choisi de supprimer, du composant implémentation, toutes les définitions représentant ces opérations de base car chaque définition est de la forme BasicOpertion(p 1,..., p n ) = Appel op importee(p 1,..., p n ). Il suffit donc de remplacer, dans les transactions chaque appel a BasicOpertion par l appel à Appel op importee. Les sous-sections suivantes décrivent la définition des opérations implémentant les prédicats et les paramètres effectifs ainsi que le raffinement des constructeurs Définition des opérations implémentant les prédicats et les paramètres effectifs La définition des opérations implémentant des prédicats et celle des paramètres effectifs étant réalisées de manière similaire, seule celle pour un prédicat est illustrée. Une opération op p est spécifiée pour chaque prédicat P utilisé dans la transaction à implémenter. Les paramètres d entrée de op p sont un sous-ensemble des paramètres

15 De B vers JAVA/SQL 15 Variable abstraite Réécriture en fonction des variables concrètes C est la variable C = x.(x Table C {x cle}) associée à une classe Att est un attribut monovalué Att = x.(x Table C x cle x Att) d une classe C ou une association monovaluée sur C Ass est une association Ass = x.(x Table Ass {x cle 1 x cle 2 }) multivaluée Att est attribut d une Att = association multivaluée Ass x.(x Table Ass {x cle 1 x cle 2 x Att}) Tableau 1. Raffinement des variables abstraites B d entrée de la transaction où est utilisé le prédicat P. Ils représentent les variables libres du prédicat P. Cette opération retourne la valeur bool(p ) où P est obtenu à partir de P par réécriture de chaque expression, faisant référence aux variables abstraites, en fonction des variables concrètes. Par exemple, l opération implémentant le prédicat caractérisant un client en règle est spécifiée comme suit : res ClientEnRegle(cl) = PRE cl client THEN res := bool( ( ca.(ca Emprunt 1 [{cl}] DateCourante DateE(ca, cl) 90))) Notons que, pour le moment, les préconditions de ces opérations ne sont pas générées automatiquement. Pour cela, on doit être capable de d inférer le typage de chaque paramètre à partir de la précondition de la transaction. Pour se faire, l approche définie dans [MAM 04b] peut être utilisée. Comme nous pouvons le remarquer, l opération ClientEnRègle fait toujours référence aux variables abstraites qui ne sont plus visibles car remplacées par les variables des machines SQL. Pour cela, il est nécessaire de réécrire les variables abstraites en fonction des variables définies dans les machines SQL. Le tableau 1 donne la réécriture de chaque variable abstraite en fonction des variables des machines importées où : x y : désigne la valeur du champ y pour l enregistrement x, cle : désigne le champ correspondant à l attribut clé d une classe, cle 1 et cle 2 : désignent les deux champs correspondant aux attributs formant la clé d une association. Par exemple, les variables Emprunt et DateE sont réécrites en : Emprunt = x.(x Table Emprunt {x EmpruntCa x EmpruntCl}) DateE = x.(x Table Emprunt {x EmpruntCa x EmpruntCl x DateE})

16 16 2 e soumission à Technique et science informatiques. Intuitivement, la définition Emprunt précédente reconstruit la fonction abstraite Emprunt à partir de l ensemble des enregistrements de la variable Table Emprunt : chaque enregistrement rec(x, y,, ) 10 de Table Emprunt désigne un tuple (x, y) de Emprunt Implémentation des constructeurs de substitutions B Rappelons que notre langage cible est le langage JAVA/SQL. L implémentation du dernier niveau de raffinement dépend étroitement du choix du langage cible. En effet, le but du raffinement est d aboutir à une spécification proche du langage cible, c.à.d, des structures de données et de contrôle qui peuvent être naturellement traduites dans le langage cible. Cette section a pour but de raffiner (implémenter plus exactement) les constructeurs de substitutions B par des structures de contrôle supportées par JAVA/SQL. Rappelons que, dans notre cas, la spécification des transactions peut comporter les constructeurs suivants : IF, ANY et Parallèle. Le raffinement du premier constructeur est assez évident, il est conservé tel quel en implémentation car il est admis en B0, supporté et a la même sémantique en JAVA, ceci n est pas le cas des deux derniers constructeurs non admis au niveau implémentation B. Nous décrivons ci-après comment nous les implémentons Implémentation du constructeur ANY En B, le constructeur ANY n est pas admis en B0. Cependant, notre langage cible SQL supporte la sélection aléatoire d un tuple vérifiant des propriétés données (Cf. Section 6.3). Afin de pouvoir conserver une substitution (ANY X WHERE P THEN S ) au dernier niveau de raffinement, on associe à cette substitution une opération op p renvoyant une valeur de la variable (ou ensemble de variables) X satisfaisant P, appelée substitution "devient tel que". Comme précédemment, les paramètres d entrée de cette opération correspondent aux variables libres du prédicat P n apparaissant pas dans X. Cette opération est spécifiée comme suit : X op p (vars libres p ) = PRE typage des paramètres THEN X :(P) Finalement, une substitution (ANY X WHERE P THEN S ) est implémentée par : (VAR X IN X op p (vars libres p ) ; S ) Afin d assurer la correction de notre processus de raffinement, nous devons montrer la faisabilité de la substitution (ANY X WHERE P THEN S ), i.e, qu il existe effectivement une valeur de X qui satisfait le prédicat P. Pour cela, pour toute opération de précondition Pre composée, entre autres, d une substitution (ANY X WHERE P THEN S ), il faut prouver : (x 1,..., x n ).(Pre X.P) 10. Le symbole " " désigne une valeur quelconque.

17 De B vers JAVA/SQL 17 avec (x 1,...,x n ) désignant les variables libres de Pre. Le non-ajout d une telle obligation de preuve conduirait à des programmes finaux qui pourraient produire des erreurs à l exécution. À ce stade, la question suivante se pose : Où doivent être définies les opérations implémentant les prédicats, les paramètres effectifs, et le constructeur ANY? Notre solution est la suivante. Si un prédicat (resp. paramètre effectif, le prédicat du constructeur ANY) ne fait référence qu aux données d une seule machine importée, alors l opération associée peut être définie dans la machine importée en question. Dans le cas contraire, nous ajoutons une machine abstraite, appelée dans la suite Utility, qui étend l ensemble des machines importées. C est dans la machine Utility que sont spécifiées les opérations implémentant les prédicats (resp. paramètres effectifs, constructeurs ANY) faisant référence à des variables définies dans des machines importées différentes. Notons que ces opérations sont prouvées automatiquement puisqu elles ne modifient pas l état du système Implémentation de la substitution parallèle Une substitution parallèle S 1 S 2 signifie que S 1 et S 2 sont exécutées simultanément, c est-à-dire sur le même état initial du système représenté par les valeurs des différentes variables. Elle est naturellement raffinée par la substitution séquence. Mais une substitution S 1 modifiant une variable v ne doit pas être exécutée avant une substitution S 2 lisant la même variable. Or, les substitutions peuvent avoir des variables communes lues et modifiées par l une et l autre réciproquement. Une solution simple est de mémoriser la valeur de chacune de ces variables avant l exécution de toute substitution. Dans notre cas, on doit évaluer les prédicats et les paramètres d entrées de chaque opération dépendant des variables abstraites avant toute exécution de substitutions. Soit S 1 S 2 une substitution parallèle élémentaire, c.à.d, S 1 et S 2 ne contiennent pas de substitution parallèle 11. L implémentation de S 1 S 2 est de la forme : (S 1 S 2 ) (VAR Var S1, Var S2 IN opval S1 ; opval S2 ; T 1 ; T 2 ) où opval Si désigne la liste des appels d opération renvoyant les valeurs des prédicats, associés au constructeurs IF ou ANY, et des paramètres effectifs utilisés par la substitution S i. Var Si est une liste d identificateurs. Chaque identificateur var k est associé à un prédicat P k ou paramètre effectif PE k qui stocke la valeur renvoyée par l opération qui lui est associée. La substitution T i est obtenue à partir de S i en remplaçant, dans S i, chaque prédicat P k par l expression var k = TRUE et chaque paramètre effectif PE k par l identificateur var k. Par exemple, la transaction LocationCassette, de la page 10, est implémentée par (les appels aux opérations de base sont implémentés par des appels aux opérations des machines SQL) : resultat LocationCassette(cl, ti) = BEGIN 11. Une substitution (S 1 Var X IN S 2 ) est réécrite en (Var X IN S 1 S 2 )

18 18 2 e soumission à Technique et science informatiques. VAR val pred 1, ca, val pred 2, val param IN /*valeur du prédicat ( ca.(ca cassette ca Emprunt 1 [{cl}] DateCourante DateE(ca, cl) 90))*/ val pred 1 ClientEnRegle(cl) ; /*génération d une valeur de ca satisfaisant le prédicat ca cassette AdresBo(Appartient(ca)) = adbo Titre(ca) =ti*/ ca RenvoiCassetteTitre(ti) ; /*valeur du prédicat NbLibre(ca) > 0*/ val pred 2 CopieDisponible(ca) ; /*évaluation du paramètre (NbLibre(ca) 1)/ val param NouvelleValNbLibre(ca) ; IF val pred 1 = TRUE THEN IF val pred 2 = TRUE THEN InsertEmprunt(ca, cl, DateCourante, OK) ; resultat :="succes" ELSE InsertEmprunt(ca, cl, DateCourante, Att) ; resultat :="att" ; IF val pred 2 = TRUE THEN UpdateNbLibre(ca, val param) ELSE resultat :="erreur" Cette solution a l avantage d être assez simple, néanmoins, elle représente un inconvénient évident. En effet, tous les prédicats et les paramètres d entrée des opérations sont évalués par anticipation. Or certaines de ces valeurs peuvent s avérer non nécessaires. Ceci est le cas, par exemple, pour la variable locale val param qui n est utilisée que si le prédicat val pred 2 est vrai. De même, l évaluation des variables locales ca, val pred 2 et val param n est utile (nécessaire) que si le prédicat val pred 1 est vrai. De plus dans certain cas, comme ici (choisi délibérément), cette solution est complètement désavantageuse. En effet, comme la substitution InsertEmprunt ne modifie aucune variable lue par la substitution UpdateNbLibre, l évaluation du paramètre (NbLibre(ca) 1) peut être différée au cas où le prédicat val pred 2 serait vrai. Pour cela, nous travaillons actuellement sur la définition d une approche plus efficace qui minimise le nombre d évaluations des prédicats et des paramètres à exécuter par anticipation. Cette approche est basée sur l étude des dépendances des substitutions/variables modifiées et substitutions/variables lues, l idée étant d exécuter en premier les substitutions modifiant le moins de variables. Plus de détails peuvent être trouvés dans [MAM 04a]. Remarquons que notre démarche d implémentation d une substitution parallèle ne considère que les variables apparaissant dans les paramètres effectifs des appels d opérations et des prédicats. En effet, si l ont considère deux opérations : (op 1 (ca) = Emprunt := {ca} Emprunt) et (op 2 (ca) = client := client Emprunt[{ca}]), l application de notre approche sur la transaction (op 1 (ca) op 2 (ca)) donnerait (op 1 ; op 2 )

19 De B vers JAVA/SQL 19 qui est évidemment incorrect dans le cas où ca est effectivement empruntée. Dans ce cas, le dépliage des appels d opération est nécessaire afin de déterminer les variables lues et modifiées par chaque substitution. Cependant, déplier les appels d opération briserait la modularité de la spécification abstraite d une opération au niveau de son implémentation. Ce dépliage rendrait difficile, voire impossible, l implémentation automatique de ces opérations. Pour cela, dans le cadre de notre travail de recherche, on pose l hypothèse qu une opération de base d une classe (resp. association) ne fait référence (en lecture ou écriture) qu aux variables B générées pour la classe (resp. l association). Cette hypothèse ne concerne pas sa précondition qui elle peut faire référence à n importe quelle variable. Une telle hypothèse n est pas une contrainte forte dans le sens où elle ne réduit en rien le pouvoir d expression d une transaction base de données. Une façon de contourner cette restriction peut être la suivante. Une opération de base op(param 1,..., param n ), sur une classe (ou association) C, devant lire une variable x générée pour une classe (ou association) y, est spécifiée en ajoutant un paramètre z à sa signature op (param 1,..., param n, z), et en remplaçant, dans le corps de op, chaque occurrence de x par le paramètre z. De cette manière, un appel op(val 1,..., val n ) est équivalent à l appel op (val 1,..., val n, x). Sur l exemple précédent, il suffit de réécrire op 2 en op 2 (ca, z) = client := client z[{ca}]), etde considérer la transaction (op 1 (ca) op 2 (ca, Emprunt)) Architecture de l implémentation B La figure 3 décrit la structure de l implémentation B obtenue à l issue de notre processus de raffinement. Trois niveaux sont à distinguer : 1) Le premier niveau est constitué des machines correspondant aux différentes tables relationnelles. Comme noté précédemment, chaque machine décrit une variable représentant une table du schéma de la base de données, et des opérations représentant les requêtes SQL de base ainsi que celles implémentant les prédicats, les paramètres effectifs et le constructeur ANY ne faisant référence qu aux données d une même classe ou association. 2) Le deuxième niveau est constitué d une seule machine étendant (lien "extends" de B) les différentes machines du niveau précédent. C est dans cette machine que sont spécifiées les opérations implémentant les prédicats, les paramètres effectifs et le constructeur ANY faisant référence à des données de classes ou associations différentes. C est dans cette machine qu est définie, par exemple, l opération ClientEn- Regle de la page 15. 3) Le dernier niveau désigne le composant "implémentation". Ce composant importe la machine du deuxième niveau. Par transitivité, les machines SQL sont également importées. Ce composant définit l implémentation des transactions en faisant appel notamment aux opérations des niveaux précédents. 6. Traduction en code SQL imbriqué dans JAVA Le but de tout processus de développement étant la production de code, cette section présente une démarche de traduction des différentes spécifications terminales B en

20 20 2 e soumission à Technique et science informatiques. composant implémentation Appels d opération Opérations implémentant les transactions lecture des variables imports Opérations implémentant les prédicats Opérations implémentant les paramètres effectifs Machine Utility Opérations implémentant les substitutions ANY extends Opérations implémentant les paramètres effectifs Opérations implémentant les prédicats Opérations représentant les requêtes de base SQL Opérations implémentant les substitutions ANY Machines SQL Figure 3. Structure de l implémentation B langage SQL imbriqué dans le langage hôte JAVA. L utilisation du langage JAVA est complètement arbitraire, un autre langage offrant les structures de contrôle absentes en SQL (Séquence, IF, etc) est tout à fait possible. Au cours de nos travaux, nous avons utilisé le SGBD Postgres version implémentant le standard SQL92, et le protocole JDBC pour l accès à la base de données. La contribution de cette partie est la définition de règles génériques permettant de traduire, en JAVA/SQL, les éléments suivants (Voir figure 4) : les machines importées SQL représentant les tables relationnelles, les opérations renvoyant la valeur des paramètres effectifs et des prédicats, les opérations représentant les transactions. La figure 4 montre l architecture de l implémentation JAVA générée à partir de l implémentation B. Trois niveaux sont à distinguer : le premier niveau correspond à la définition du schéma de base de données dans le SGBD, le second contient un ensemble de classes JAVA définissant les requêtes SQL sur les différentes tables. Les méthodes de ces classes font appel aux méthodes des classes de JDBC pour accéder et exécuter des requêtes sur la bases de données. Enfin le dernier contient les classes JAVA traduisant les transactions ainsi que des opérations renvoyant les valeurs des prédicats et des paramètres effectifs. Les méthodes de ce dernier niveau font appel aux méthodes du niveau précédent.

21 De B vers JAVA/SQL 21 SGBD: PostgresSQL Tables relationnelles requêtes sur la BD niveau JAVA classes JAVA implémentant les ordres de base Appels des méthodes du JDBC classes JAVA réalisant l interface avec le SGBD Appels des méthodes traduisant les opérations de base classes JAVA implémentant les transactions, prédicats, Figure 4. Architecture de l application JAVA/SQL 6.1. Traduction des machines SQL Les machines SQL modélisent le schéma de la base de données ainsi que les requêtes de base SQL. À chaque machine A Rel on fait correspondre : un schéma de table relationnelle A définissant la structure de la table une classe JAVA A définissant un ensemble de méthodes traduisant les opérations définies dans la machine A Rel et qui correspondent soit aux requêtes de base ou à l évaluation de prédicats ou de paramètres effectifs. Nous décrivons, ci-après, les règles de traduction permettant la génération du schéma de la table et de la classe JAVA associée. Dans cette section, seule la traduction des opérations correspondant aux requêtes de base est décrite. La traduction des opérations implémentant les prédicats, les paramètres effectifs et le constructeur ANY est décrite dans les sections suivantes Génération du schéma de la base de données Chaque machine importée SQL définit une table relationnelle dont le schéma est généré en appliquant les règles formelles suivantes : a) Définition des champs de la table Trad B SQL(Table C struct(att 1 : T 1,...,Att n : T n))= CREATE TABLE C(

22 22 2 e soumission à Technique et science informatiques. Att 1 Trad B SQL(Att 1 : T 1) NULL Constraint,... Att n Trad B SQL(Att n : T n) NULL Constraint PRIMARYKEY Constraint, UNIQUE Constraint, REFERENTIAL Constraint) b) Typage des champs Trad B SQL(Att : NAT)=INT Check Att 0 Trad B SQL(Att : BOOL) =BOOLEAN Trad B SQL(Att : STRING) =CHAR(n) avec n un entier fixe. Trad B SQL(Att : {val 1,...val n}) =CHAR(n) Check Att IN ("val 1",...,"val n") avec n un entier fixe désignant la longueur du plus long identificateur val i. c) Définition des contraintes //si la fonction B correspondant à un attribut est totale, le champ est contraint à être non nul Trad B SQL(Att i C T i)=not NULL //la clé d une table C désigne la fonction injective sur C //(ou les fonctions dont le produit direct est injectif sur C) Trad B SQL(Att i... Att j C T i... T j)=primary KEY (Att i,..., Att j) //les autres fonctions injective sont décrites par UNIQUE Trad B SQL(Att m... Att n C T m... T n)=unique (Att m,..., Att n) //l invariant de collage introduit par l élimination d une association monovaluée //est traduit par une contrainte référentielle Trad B SQL(Att 1 =(Att 2 ;Cle D))=Att 1 REFERENCES D(Cle D) //l invariant de collage introduit par l élimination des associations multivaluées //est traduit par deux contraintes référentielles Trad B SQL(C A B Att 1 = C (prj 1(A, B) ;Cle A))=Att 1 REFERENCES A(Cle A) Trad B SQL(C A B Att 2 = C (prj 2(A, B) ;Cle B))=Att 2 REFERENCES B(Cle B) Génération de la classe JAVA définissant les requêtes de base Chaque opération définie dans une machine SQL est traduite par une méthode JAVA. Ces méthodes sont définies dans une même classe JAVA A. Le squelette de cette classe est généré par la règle suivante : ÌÖ ÂËÉÄ Å ÀÁÆ Ê ººº Æ µ ÔÙ ß» Ö Ø ÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø» ººº» Ò Ø ÓÒ ³ÙÒ ÓÒÒ Ü ÓÒ Ø Ê» ÔÖ Ú Ø ÓÒÒ Ø ÓÒ ÓÒÒ» Ö Ø ÓÒ ³ÙÒ Ò Ø Ò» ÔÙ ÓÒÒ Ø ÓÒ ÓÒÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß Ø ºÓÒÒ ÓÒÒ» Ò Ø ØÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø»

23 De B vers JAVA/SQL 23 ººº» Ö Ø ÓÒ Ñ Ø Ó» ººº La déclaration des variables stockant les requêtes, leurs définitions ainsi que le code associé aux méthodes sont obtenus par la traduction des opérations des machines SQL. Dans ce rapport, nous donnons les règles de traduction des opérations d ajout d un tuple dans une table ainsi que celle permettant la mise à jour de la valeur d un attribut. Plus de détails peuvent être trouvés dans [MAM 02]. a) Opération d ajout d un tuple Trad B JSQL(InsertionA(p 1,..., p n) = PRE p 1 T 1... p n T n THEN Table A := Table A {rec(p 1,..., p n)} )=» Ö Ø ÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø» ÔÖ Ú Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÁÒ ÖØ» Ò Ø ØÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø» ØÑØÁÒ ÖØ ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ò ÖØ ÒØÓ Øؽ ººº ØØÒµ Ú Ù ººº µµ µ» ÓÙØ ³ÙÒ ÒÓÙÚ Ò Ø Ò Ò ÓÒÒ» ÔÙ ÚÓ ÁÒ ÖØ Ì½ Ô½ ººº ÌÒ ÔÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß» Ø Ø ÓÒ Ú ÙÖ ÙÜ Ö ÒØ ÑÔ» ØÑØÁÒ Öغ Ø̽ ½ Ô½µ ººº ØÑØÁÒ Öغ ØÌÒ Ò ÔÒµ» Ü ÙØ ÓÒ ³ Ò ÖØ ÓÒ» ØÑØÁÒ Öغ Ü ÙØ ÍÔ Ø µ b) Opération de mise à jour d un attribut Att i Trad B JSQL(UpdateAtt i(p 1, p 2) = PRE p 1 T 1 p 2 T i THEN ANY xx WHERE xx Table A xx att 1 = p 1 THEN Table A := Table A {xx} {rec(xx Att 1,..., xx Att i 1, p 2,..., xx Att n)} )=» Ö Ø ÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø» ÔÖ Ú Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÍÔ Ø ØØ» Ò Ø ØÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø» ØÑØÍÔ Ø ØØ ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ ÍÔ Ø Ø ØØ Û Ö Øؽ µ µ ÔÙ ÚÓ ÍÔ Ø Æ Ä Ö Ì½ Ô½ ̾ Ô¾µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß» Ø Ø ÓÒ Ú ÙÖ ÙÜ Ö ÒØ ÑÔ» ØÑØÍÔ Ø ØØ º Ø̽ ½ Ô½µ ØÑØÍÔ Ø ØØ º Ø̾ ¾ Ô¾µ» Ü ÙØ ÓÒ Ñ ÓÙÖ»

24 24 2 e soumission à Technique et science informatiques. ØÑØÍÔ Ø ØØ º Ü ÙØ ÍÔ Ø µ Pour chaque opération de la machine importée, une variable de type PreparedStatement est déclarée. PreparedStatement est une classe permettant de stocker une requête SQL pré-compilée. Cette classe, faisant partie du JDBC, définit un ensemble de méthodes comme l affectation de valeurs aux différents paramètres de la requête (SetTi, Ti désignant un type JAVA), l exécution de la requête (executeupdate), etc. L avantage d utiliser une variable PreparedStatement paramétrée (par "?") est d améliorer la performance du programme final. En effet lors de la première exécution de la requête "insert into A (Att1,..., Attn) values(?,...,?))" pour des valeurs données (v 1,...,v n ), un plan d exécution optimal d accès à la table concernée est établi et est sauvegardé. Ce même plan est réutilisé lors des prochaines exécutions de la même requête pour n importe quelles autres valeurs (v 1,...,v n ), économisant ainsi le temps de calcul d un nouveau plan d exécution Traduction des prédicats et des expressions B Comme nous l avons vu précédemment, les prédicats et les expressions B utilisés dans la spécification des transactions sont implémentés par des opérations B renvoyant leurs valeurs. Dans ce qui suit, nous donnons la traduction JAVA/SQL d un prédicat, celle correspondant à une expression s obtient de manière similaire. Pour chaque opération op p, implémentant le prédicat p, une classe JAVA P est créée. Cette classe définit une méthode Val implémentant le corps de l opération op p : ÔÙ Èß ÔÙ Ø Ø ÓÓ Î Ú Ö Ö Èµß Ö ØÙÖÒ Ú ÙÖ ÓÓ ÒÒ Èµ La méthode Val peut faire appel à des méthodes privées pour l évaluation des différentes parties du prédicat P. Les prédicats étant construits inductivement sur des prédicats élémentaires construits eux-mêmes sur des expressions, la traduction de ces derniers en JAVA/SQL est définie inductivement sur leur forme décrite par : Predicat ::=Predicat Log Oper Predicat Predicat X. Predicat X. (Predicat Predicat) Expression Set Op Log Expression ; ; Log Oper ::= ;; Set Op Log = =...;; Expression ::=Value Expression Set Expression ;; Value Expression ::=min(set Expression) max(set Expression) Expression Att Ass(Value Expression, Value Expression) Expression Att Class(Value Expression) card(set Expression) Value Expression Arith Op Value Expression Int String TRUE FALSE {}...;; Expression Att Class ::=ident 1 Expression Att Class Set Op Expression Att Class Expression Att Ass ::=ident 2 Expression Att Ass Set Op Expression Att Ass Set Expression ::=ident 3 dom(set Expression) ran(set Expression) Ass Att[Set Expression]

25 De B vers JAVA/SQL 25 Ass Att 1 [Set Expression] Set Expression Set Op Set Expression Set(Value Expression) ;; Ass Att ::=ident 2 Ass Att Set Op Ass Att Set Op ::= - ;;Arith Op = {+,, } ;; avec : Value Expression : désigne toute expression renvoyant une valeur d un des types de base. Set Expression : désigne toute expression faisant référence à une variable abstraite et renvoyant une valeur ensembliste. String et Int désignent des constantes de type String et Int respectivement. ident 1 représente une variable traduite comme un champ d une table représentant une classe. ident 2 représente une variable traduite comme un champ d une table représentant une association. ident 3 représente une variable abstraite quelconque traduite par une table ou un champ d une table. Set(Value Expression) représente un ensemble de valeurs d un des types de base : Set(Int), Set(String), etc. Il est important de noter qu une expression de la forme Expression Att Class(resp. Expression Att Ass, Ass Att) ne peut faire référence qu aux attributs d une même classe (resp. même association, des associations définies sur les même classes). En effet dans le cas contraire, le typage de l expression serait incorrect. Dans ce qui suit, nous présentons quelques cas de traduction de prédicats illustrés sur notre cas d étude. Les autres cas se traitent de manière similaire. Comme nous sommes souvent amenés à opérer avec des expressions ensemblistes (appartenance, test d égalité, test d inclusion etc), nous avons créé une classe JAVA, nommée VectorSet gérant les ensembles d objets JAVA et implémentant ces différentes opérations ensemblistes. Le code de cette classe est donné dans [DOL 03] Cas des expressions B. La traduction des expressions B en JAVA/SQL est définie inductivement sur la forme de ces dernières. En posant l hypothèse que les opérateurs arithmétiques ont la même sémantique en JAVA et B dans le cas de non-débordement arithmétique, ces opérateurs restent inchangés lors de la traduction. Afin d avoir un nombre minimum de règles de traduction d expressions B vers JAVA, une étape de simplification est nécessaire. Le but de cette étape est de réduire chaque expression contenant des opérateurs ensemblistes en une expression sans opérateurs. Cette simplification est nécessaire car la sélection d un tuple en SQL ne peut se faire que sur une table unique qui peut être évidemment la combinaison de plusieurs tables. En effet, si on considère définie une deuxième association multivaluée Reservation entre les classes Cassette et Client, le choix d une cassette quelconque empruntée ou réservée

26 26 2 e soumission à Technique et science informatiques. Exp TempTable(Exp) Champs(Exp) e 1 e 2 TempTable(e 1 ) UNION TempTable(e 2 ) Champs(e 1 ) e 1 e 2 TempTable(e 1 ) INTERSECT TempTable(e 2 ) Champs(e 1 ) e 1 e 2 TempTable(e 1 ) EXCEPT TempTable(e 2 ) Champs(e 1 ) dom(ident 1 ) Ass.ReadCle 1 cle 1 ident 2 C.ReadIdent 2 (cle, ident 2 ) ident 1 Ass.ReadCle (cle 1, cle 2 ) ident 3 C.ReadCle cle Tableau 2. Construction des tables temporaires (ca dom(emprunt) dom(reservation)) doit être traduit, en SQL, par une requête agissant sur l union des deux tables. Une telle réduction permet également de réduire l imbrication des requêtes SQL traduisant les expressions. L idée clé est l utilisation de tables temporaires stockant les valeurs de ces expressions. Pour chacune des expressions Expression Att Class, Expression Att Ass et Ass Att contenant des opérateurs ensemblistes et dépendant des variables abstraites, une table temporaire est créée pour stocker les valeurs de ces expressions. Les champs et le contenu d une table temporaire associée à ( exp = A Set Op B) sont calculés par induction sur la forme de exp. Les colonnes TempTable et Champs du tableau 2 définissent inductivement le contenu et les champs de la table temporaire associée à une expression où : ident 1 désigne une table traduisant une association multivaluée, cle 1 et cle 2 désignent les attributs clés de la table. Par exemple, ident 1 = Emprunt. ident 2 désigne un champ d une table traduisant une classe C, cle désigne la clé de la table. Par exemple, ident 2 = Titre. ident 3 désigne une table traduisant une classe, cle désigne la clé de la table. Par exemple, ident 3 = cassette. XX.YY : désigne la méthode YY définie dans la classe associée à la table XX. Ass.ReadCle 1 (resp Ass.ReadCle 2 ) : renvoie l ensemble des valeurs du premier (deuxième ) attribut clé d une table traduisant une association multivaluée. C.ReadIdent 2 : renvoie l ensemble des couples (a,b) tels que a est la valeur de champ clé, et b la valeur de l attribut ident 2. Ass.ReadCle : renvoie l ensemble des couples de valeurs des attributs clé d une table traduisant une association. C.ReadCle : renvoie l ensemble des valeurs de l attribut clé d une table traduisant une classe. Par exemple, le champ de la table temporaire associée à l expression (dom(emprunt) dom(reservation)) est EmpruntCa. Le contenu de cette table est (Emprunt.ReadCle 1 Reservation.ReadCle 1 ). Ayant évalué chaque expression contenant des opérateurs ensemblistes, le tableau 3 donne quelques exemples de traduction d expressions en JAVA. Une description plus détaillée peut être trouvée dans [DOL 03].

27 De B vers JAVA/SQL 27 Expression Traduction JAVA/SQL Sémantique ident 1 1 [Y] ident 1.GetAntec(Y) renvoie l ensemble des antécédents de Y par l association ident 1 ident 4 (u, v) ident 1.ReadIdent 4 Tuple(u, v) renvoie la valeur de l attribut ident 4, de l association ident 1, pour le tuple (u, v) ident 3 ident 3.ReadCle renvoie l ensemble des valeurs de l attribut clé ident 2 (x) C.ReadIdent 2 Tuple(x) renvoie la valeur de l attribut ident 2 pour le tuple dont la clé est x Tableau 3. Traduction des expressions concrètes en JAVA/SQL Par exemple, la méthode JAVA GetAntec est définie par (cle 1 et cle 2 désignent les attributs de la clé de la table ident 1 ): ÔÙ Ê ÙØË Ø Ø ÒØ Î ØÓÖË Ø Ýµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØ» ÓÒ ØÖÙØ ÓÒ Ò Ö Ø Ö ÓÖÖ ÔÓÒ ÒØ ÙÜ Ú ÙÖ Ý» ËØÖ Ò Ò Û ËØÖ Ò Ø ½ ÖÓÑ Òؽ Û Ö ¾ Ò µ ÓÖ ÒØ ¼ ݺ Þ µ ¹ ½ µ µ ØÑØ ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ µ» Ø Ø ÓÒ Ú ÙÖ ÙÜ Ö ÒØ ÑÔ» ÓÖ ÒØ ¼ ݺ Þ µ µ ß» Ì Ò ØÝÔ ¾» ØÑغ ØÌ ½ ̵ ÝºÚ ØÓÖ µµº Ñ ÒØ Ø µµ» Ü ÙØ ÓÒ Ö ÕÙ Ø» Ê ÙØË Ø Ö Ø ØÑغ Ü ÙØ ÉÙ ÖÝ µ Ö ØÙÖÒ Ö Ø La méthode elementat(i) renvoie l élément d indice i d un vecteur donné. y.vector renvoie une représentation vectorielle d un ensemble. L opération ne faisant référence qu aux champs de la table Ass, cette dernière peut être définie dans la classe JAVA traduisant l association ident 1. L opération GetAntec étant générique, il suffit de l instancier pour obtenir l opération correspondant à Emprunt 1 [{cl}] : on remplace cl 1 par EmpruntCa, ident 1 par Emprunt et cl 2 par EmpruntCl Cas du prédicat P = Exp 1 Set Op Log Exp 2. La méthode JAVA implémentant ce prédicat appelle les méthodes d évaluation des expressions si besoin est, puis, applique les opérateurs adéquats offerts par la classe VectorSet. ÔÙ Ø Ø ÓÓ Ò È Ú Ö Ö Èµ ß Î ØÓÖË Ø ÜÔ½ Ú Ù Ø ÓÒ ÜÔ½ Î ØÓÖË Ø ÜÔ¾ Ú Ù Ø ÓÒ ÜÔ¾

28 28 2 e soumission à Technique et science informatiques. Ö ØÙÖÒ ÜÔ¾ºÜÜÜÜÜ ÜÔ½µ xxxxx est la fonction correspondant à Set Op Log. Ainsi par exemple : donne exp2.contains(exp1). Dans ce cas là, exp1 sera un Objet et non un VectorSet. Dans le cas des types primitifs, int et float par example, il est nécessaire de transformer la valeur en un objet. Par exemple, la méthode TestCassetteEmpruntee, décrite ci-dessous, transforme l entier ca en un objet de type Integer. donne exp2.containsall(exp1); donne exp2.strictcontainsall(exp1) ; = donne exp2.equals(exp1) ; Par exemple, la méthode TestCassetteEmpruntee testant si une cassette ca est empruntée par le client cl (ca Emprunt 1 [{cl}]) est exprimée en JAVA par : ÔÖ Ú Ø ÓÓ Ò Ì Ø ØØ ÑÔÖÙÒØ ÒØ ÒØ µß»»øö Ò ÓÖÑ Ö Ò Ú Ø ÙÖº Î ØÓÖË Ø ½ Ò Û Î ØÓÖË Ø µ ½º µ»»ö ØÖÓÙÚ Ö ÑÔÖÙÒØ Ù ÒØ Î ØÓÖË Ø ÑÔ Ò Û Î ØÓÖË Ø ÑÔÖÙÒغ Ø ÒØ ½µµ»» Ø Ö Ò ÙÒ Ó Ø ØÝÔ ÒØ Ö ÁÒØ Ö Ö ½ Ò Û ÁÒØ Ö µ»»ø Ø ³ ÔÔ ÖØ Ò Ò ÑÔ Ö ØÙÖÒ ÑÔºÓÒØ Ò ½µ Cas du prédicat existentiel Dans un prédicat existentiel (P = X.P 1 ),X désigne un ensemble de variables {x 1,...,x n }. Par construction du prédicat existentiel, les premiers sous-prédicats de P 1, permettent de typer les différentes variables x i. Dans ce rapport, nous supposons que chaque variable x i de X, est typée par un sous-prédicat de la forme x i X i. Le prédicat P est donc de la forme : x 1,...x n (( i=1..n x i X i ) P 2 ). Chaque sous-prédicat x i X i fournit l ensemble des valeurs possibles de la variable x i. Pour déterminer la valeur de P, on doit tester les différentes combinaisons possibles des valeurs des variables x i, jusqu à obtenir une combinaison qui satisfait P 2. Concrètement, on crée un VectorSet contenant les valeurs de X 1 (par exemple), ces valeurs sont ensuite parcourues par une boucle sur x 1. Pour chaque valeur x 1, on crée un VectorSet contenant les valeurs de X 2 (par exemple), ces valeurs sont ensuite parcourues par une boucle sur x 2, et ainsi de suite, jusqu à obtenir une valeur qui satisfait P 2, sinon on renvoie False : ÔÙ Ø Ø ÓÓ Ò È Ú Ö Ö Èµß ÓÓ ØÖÓÙÚ Î ØÓÖË Ø Úܽ Ò Û Î ØÓÖË Ø ½µ ÓÖ ÒØ ½ ¼ ½ Úܽº Þ µµ ²² ØÖÓÙÚ µ ½ µß» ¾ Ø Ó Ø ÒÙ ÔÖ Ö ÑÔ Ñ ÒØ Ú ÙÖ Ü½» Î ØÓÖË Ø Úܾ Ò Û Î ØÓÖË Ø ¾µ ÓÖ ÒØ ¾ ¼ ¾ Úܾº Þ µµ ²² ØÖÓÙÚ µ ¾ µß ººº

29 De B vers JAVA/SQL 29 Î ØÓÖË Ø ÚÜÒ Ò Û Î ØÓÖË Ø Òµ ÓÖ ÒØ Ò ¼ Ò ÚÜÒº Þ µµ ²² ØÖÓÙÚ µ Ò µ ØÖÓÙÚ È¾ ÚܽºÚ ØÓÖ µµº Ñ ÒØ Ø ½µ ººº ÚÜÒºÚ ØÓÖ µµº Ñ ÒØ Ø Òµ ºººµ Ö ØÙÖÒ ØÖÓÙÚ L appel à la méthode P2 peut inclure d autres paramètres effectifs. La traduction proposée peut être coûteuse en terme de mémoire et de temps d exécution. Ce coût peut être réduit notamment en ordonnant les parcours des variables en commençant par les variables dont le nombre de valeurs est le plus petit. Une telle optimisation nécessite l intervention de l utilisateur. Par exemple, la méthode ClientEnRetard est exprimée par (RetardClientCassette(ca, cl) teste si le client cl est en retard sur la cassette ca): ÔÙ ÓÓ Ò ÒØ ÒÊ Ø Ö ÒØ µ ß ÓÓ Ò ØÖÓÙÚ» ÓÒ ØÖÙØ ÓÒ ³ Ò Ñ ß» Î ØÓÖË Ø ½ Ò Û Î ØÓÖË Ø µ ½º µ» Ö ØÖÓÙÚ Ö ³ Ò Ñ ÑÔÖÙÒØ» Î ØÓÖË Ø Ò Û Î ØÓÖË Ø ÑÔÖÙÒغ Ø ÒØ ½µµ ÒØ ÓÖ ¼ º Þ µ ²² ØÖÓÙÚ µ µß ÒØ ÁÒØ Öµ ºÚ ØÓÖ µµº Ñ ÒØ Ø µµº ÒØÎ Ù µ ØÖÓÙÚ Ê Ø Ö ÒØ ØØ µ Ö ØÙÖÒ ØÖÓÙÚ Cet algorithme est correct sous la condition que chacun des ensembles X i soit fini. Cela revient à dire que X i doit désigner une variable B différente d un des ensembles abstraits ou des types de base B. En effet, toutes les autres variables de la spécification désignent les ensembles d instances existantes, à un instant donné, et dénotent donc des ensembles finis. En base de données, un exemple typique de recherche d un élément dans un ensemble infini est la génération d une nouvelle valeur entière de la clé pour une instance donnée. Dans [MAM 02], nous avons présenté une solution pratique qui consiste à prendre le successeur de la valeur maximale des clés déjà attribuées. Pour les autres types, comme String, une fonction de génération aléatoire de chaînes de caractères doit être définie. Ceci ne rentre pas dans le cadre de ce travail Traduction des substitutions indéterministes devient tel que Les substitutions indéterministes "devient tel que" ont été introduites au dernier niveau de raffinement pour implémenter les substitutions ANY (voir section 5.2.1). Une opération op utilisant une telle substitution est de la forme : x 1,...x n op(par 1,..., par n ) = PRE par 1 T 1... par n T n THEN x 1,..., x n :(P) Comme pour le prédicat existentiel, les premiers sous-prédicats de P, P 1,...,P n, servent à typer les différents identificateurs {x 1,..., x n }. Dans ce rapport, nous considérons des

30 30 2 e soumission à Technique et science informatiques. prédicats de typage utilisant soit l appartenance (P i = x i Expression) ou l inclusion (P i = x i Expression). La substitution de op est donc de la forme : S = x 1,..., x n :( i=1..n (P i) P ) avec P un prédicat quelconque. L opération op est traduite en JAVA par une méthode dont la structure est la suivante : ÔÙ Ê ÙØË Ø ÓÔ Ì½ Ô Ö½ ººº ÌÒ Ô Öҵ߻» Ò Ø ÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø ÔÖ Ú Ø ÈÖ Ô Ö Ø Ø Ñ ÒØ Ö ÕÙ Ø ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ø ÑÔ ÖÓÑ Ä Ø Ø Û Ö ÈÖ µ»» Ø Ø ÓÒ Ú ÙÖ ÙÜ ÑÔ Ø Î ÑÔ»» Ü ÙØ ÓÒ Ö ÕÙ Ø Ê ÙØË Ø Ö ÙØ Ö ÕÙ Ø º Ü ÙØ ÉÙ ÖÝ µ»»ö ÒÚÓ Ù Ö ÙØ Ø Ö ØÙÖÒ Ö ÙØ où champs désignent une liste des champs des tables, Liste tables désigne une liste de tables, et Pred un prédicat traduisant P. Les sous-prédicats P i doivent être également pris en compte lors du calcul du prédicat Pred. En effet en plus du typage, les prédicats P i peuvent également exprimer des contraintes sur les paramètres x i. Par exemple, le prédicat (P i = ca Emprunt[{cl}]) exprime que ca est de type cassette, mais il exprime également que ca est une cassette empruntée par le client cl. Nous décrivons dans la suite comment sont dérivés ces différents éléments à partir de l opération op. Le but de ce rapport n est pas de donner des règles complètes de traduction d une substitution "devient tel que" en SQL, mais plutôt de montrer la faisabilité d une telle traduction. La définition d un algorithme complet est un travail de recherche à part entière qui constitue une perspective intéressante de ce travail. Comme pour la traduction des prédicats, nous considérons que les expressions ont été simplifiées par la création de tables temporaires Définition des tables et des champs Les tables nécessaires à l exécution de la requête sont définies à partir du sousprédicat i=1..n (P i). Dans ce rapport, nous présentons le cas où les prédicats P i désignent des prédicats d appartenance, le cas de l inclusion se traite de manière similaire. De même, les champs sont définis en parcourant les prédicats P i. Le tableau 4 donne quelques exemples montrant comment les tables relationnelles et les champs sont induits en fonction de la forme de chaque prédicat P i où : ident 1 représente le nom d une table traduisant une classe de clé cle. Par exemple, cassette, client, boutique. ident 2 représente un champ d une table C traduisant une classe de clé cle. Par exemple, Titre pour la table cassette.

31 De B vers JAVA/SQL 31 ident 3 représente le nom d une table traduisant une association de clé (cle 1, cle 2 ). Par exemple, Emprunt. exp désigne une expression quelconque. P Table(P) Champ(P) x ident 1 ident 1 cle x ident 2 C (cle, ident 2 ) x ident 2 (exp) C ident 2 x ident 2 [exp] C ident 2 x ident 3 [exp] ident 3 cle 2 x ident 1 2 [exp] C cle x ident 1 3 [exp] ident 3 cle 1 x ran(ident 2 ) C ident 2 x ran(ident 3 ) ident 3 cle 2 Tableau 4. Définition des tables relationnelles et des champs Par exemple, à partir du prédicat (ca Emprunt 1 [{cl}]), on déduit que la recherche doit être faite sur la table Emprunt en sélectionnant le champ EmpruntCa.De même, à partir du prédicat (ca cassette), on déduit que la recherche doit être faite sur la table Cassette en sélectionnant le champ NumCa. Afin de faciliter l écriture du prédicat de la clause Where, nous associons à chaque table de la clause From un identificateur qui représente un tuple quelconque de cette table. On suppose ainsi que l identificateur ca 1 est associé à la table cassette Définition du prédicat de la clause where En SQL, la clause Where d une requête exprime une propriété qui doit être satisfaite par les tuples sélectionnés. Dans ce rapport nous nous restreignons au cas où le prédicat P ne contient pas de quantificateurs universel ou existentiel. La traduction de P se réduit donc à la traduction des expressions. En effet, les connecteurs logiques (,, ) sont équivalents aux opérateurs logiques (and, or, not) de SQL. Il en est de même pour les opérateurs d appartenance, d inclusion et d égalité ( et, "=") traduits également en leurs équivalents SQL (IN et "="). La traduction des expressions en SQL est très similaire à celle présentée à la section La différence réside dans le fait que les expressions apparaissant dans la clause WHERE font référence aux identificateurs x i dont les valeurs sont inconnues. Comme chacun de ces identificateurs x i représente la valeur d un champ c d une table représentée elle-même par un identificateur a, chaque référence à x i est remplacée par a.c. De même, les références aux paramètres par i sont remplacées par des "?" qui sont par la suite instanciés par les valeurs des paramètres effectifs. Par manque de place, nous donnons un seul exemple de règle de traduction de ces expressions. Soit l expression ident(exp) où ident désigne un champ d une table T dont la clé est cle, et expr une expression quelconque. Pour traduire cette expression, trois cas sont à distinguer :

32 32 2 e soumission à Technique et science informatiques. 1) si la table T est déjà présente dans la clause From pour laquelle un identificateur t a été assigné, et exp désigne une des variables x i (exp = x i ), alors l expression est traduite simplement par : t.ident. Par exemple, l expression Titre(ca) est traduite par ca 1.Titre. 2) si exp désigne un des paramètres par i, alors l expression est traduite par : "SE- LECT ident FROM T WHERE ident=?". Une instruction d affectation de la valeur param i au "?" est également générée. 3) si exp désigne une expression quelconque, ident(expr) est traduit par : SELECT ident FROM TtWHERE t.cle=(traduction SQL de exp) Par exemple, le prédicat (ca cassette AdresBo(Appartient(ca)) = adbo Titre(ca) =ti) est traduit par : SELECT ca 1.NumCa FROM cassette ca 1 WHERE?=(SELECT bo.adresbo FROM Boutique bo WHERE bo.numbo =(ca 1.Appartient)) and ca 1.Titre =? Enfin, l opération RenvoiCassetteTitre se traduit par la méthode JAVA suivante : ÔÙ ÒØ Ê ÒÚÓ ØØ Ì ØÖ ËØÖ Ò Ø ËØÖ Ò Óµß»» Ò Ø ÓÒ Ú Ö ØÓ ÒØ Ö ÕÙ Ø ÔÖ Ú Ø ÈÖ Ô Ö Ø Ø Ñ ÒØ Ö ÒÚ ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ø ½ºÆÙÑ ÖÓÑ ØØ ½ Û Ö Ø Óº Ö Ó ÖÓÑ ÓÙØ ÕÙ Ó ÓºÆÙÑ Ó ½º ÔÔ ÖØ Òص Ò ½ºÌ ØÖ µ»» Ø Ø ÓÒ Ú ÙÖ ÙÜ ÑÔ Ö ÒÚ ºË ØËØÖ Ò ½ Óµ Ö ÒÚ ºË ØËØÖ Ò ¾ Ø µ»» Ü ÙØ ÓÒ Ö ÕÙ Ø Ê ÙØË Ø Ò Ö ÒÚ º Ü ÙØ ÉÙ ÖÝ µ»»ôó Ø ÓÒÒ Ñ ÒØ ÙÖ ÔÖ Ñ Ö Ñ ÒØ Ò ºÒ ÜØ µ Ö ØÙÖÒ Ò º ØÁÒØ ½µµ Remarquons que le prédicat (ca cassette) n a pas été traduit car ce prédicat peut être considéré redondant avec le prédicat Titre(ca) =ti. En effet, si un objet a un titre, on peut en déduire que c est une instance de cassette. Afin donc d obtenir une meilleure traduction des prédicats, il est nécessaire d inclure une phase de simplification qui élimine des parties redondantes [MAM 04b]. L opération RenvoiCassetteTitre peut aussi être réécrite en utilisant une jointure des tables Cassette et Boutique. La requête renvcas serait réécrite alors en : Ë Ø ½ºÆÙÑ ÖÓÑ ØØ ½ ÂÇÁÆ ÓÙØ ÕÙ Ó ÇÆ ½º ÔÔ ÖØ ÒØ ÓºÆÙÑ Ó Û Ö Ø ØÖ Ò Ö Ó

33 De B vers JAVA/SQL 33 La définition de règles formelles permettant la génération d une telle écriture ne semble pas évidente à moins de considérer la jointure de toutes les tables, ce qui engendrerait un coût mémoire important Traduction des transactions La traduction en JAVA des transactions est basée sur la traduction des différentes opérations d évaluation des prédicats et des paramètres effectifs effectuée. Elle correspond plus précisément à la traduction des structures de substitutions B. Cette traduction est évidemment immédiate puisque les constructeurs de substitutions B utilisées dans notre cas (IF, Séquence) sont supportées par le langage JAVA. La traduction de la transaction LocationCassette est la suivante : ÔÙ ËØÖ Ò ÄÓ Ø ÓÒ ØØ ÒØ ËØÖ Ò Ø ËØÖ Ò Óµß ËØÖ Ò Ö ÙØ»»Ø Ø Ö ÒØ ÙÒ Ö Ø Ö ÙÖ ÙÒ ØØ ÓÓ Ò Ú ÔÖ ½ ÒØ ÒÊ Ø Ö ºÎ µ»»ö Ö ³ÙÒ ØØ Ø ØÖ Ø ØÖÓÙÚ ÒØ Ò ÙÒ ÓÙØ ÕÙ ³ Ö Ó ÒØ Ê ÒÚÓ ØØ Ì ØÖ Ø Óµ»»Ø Ø Ö ÙÒ ÓÔ ØØ Ø ÔÓÒ ÓÓ Ò Ú ÔÖ ¾ ØØ º ÓÔ ÔÓÒ µ»» Ù Ö ÒÓÙÚ Ú ÙÖ Æ Ä Ö ÒØ Ú Ô Ö Ñ ÆÓÙÚ Î Æ Ä Ö µ Ú ÔÖ ½ ØÖÙ µ ß Ú ÔÖ ¾ ØÖÙ µ ß ÑÔÖÙÒغÁÒ ÖØ ÑÔÖÙÒØ Ø ÓÙÖ ÒØ Çà µ Ö ÙØ Ù ß ÑÔÖÙÒغÁÒ ÖØ ÑÔÖÙÒØ Ø ÓÙÖ ÒØ ØØ µ Ö ÙØ ØØ Ú ÔÖ ¾ ØÖÙ µ ØØ ºÍÔ Ø Æ Ä Ö Ú Ô Ö Ñµ Ö ÙØ ÖÖ ÙÖ Ö ØÙÖÒ Ö ÙØ 7. Travaux similaires Au cours de cette dernière décennie, plusieurs travaux de recherche ont été menés sur l opportunité d appliquer les méthodes formelles au domaine des applications bases de données. Ces travaux peuvent être classés en deux catégories. Les travaux de la première catégorie proposent de coupler les notations graphiques, largement utilisées dans les méthodes classiques de développement, avec des notations formelles telles que B[MAR 02, NGU 98, LED 02, TRE 02], Z[DUP 00, HAL 90, KIM 99, KIM 02], etc. La traduction des notations graphiques en notations formelles permet l obtention de modèles sur lesquels il est possible de raisonner et de mener des preuves de correction. Bien que de telles approches constituent une avancée significative pour l intégration des méthodes formelles aux processus de développement, elles ne couvrent pas l ensemble des phases du développement d une application.

34 34 2 e soumission à Technique et science informatiques. Dans [LAL 02, LAL 01], nous avons proposé un processus similaire de traduction d un sous-ensemble de diagrammes UML, spécialisés pour la description des applications bases de données, en notations B. Les travaux de la seconde catégorie utilisent la technique de raffinement pour la génération de code exécutable à partir de spécifications formelles. Les travaux les plus représentatifs de cette catégorie sont ceux présentés dans [EDM 92, EDM 95, SCH 91, GUN 93, QIA 93]. Dans [SCH 91, GUN 93], la génération de code exécutable DBPL à partir de spécifications B traduisant une spécification TDL est présentée. DBPL est un langage de programmation de bases de données relationnelles. Ce langage est basé sur une extension du modèle relationnel intégré dans le langage de programmation Modula-2. Il est plus puissant que le langage SQL. TDL est un langage similaire au langage B. En TDL, les données sont décrites par un ensemble de classes liées par des attributs. L aspect dynamique du système est décrit par un ensemble de transitions (opérations) défini sur les classes. Une transition est spécifiée dans un style de pré-post condition. La traduction de spécifications B en code DBPL est formalisée comme une réécriture dans le système OBJ[GOG 00]. L inconvénient principal de cette approche est que des règles de raffinement ne sont définies que pour la partie données d une application. Dans [EDM 92, EDM 95], une approche de dérivation d une implémentation relationnelle à partir de spécifications Z est proposée. Cette approche est illustrée à travers un exemple pratique, aucune règle formelle n est définie. Quian [QIA 93] a défini une logique de description de transactions bases de données et des règles de déduction basées sur la technique des tableaux déductifs pour la génération du code. Cette approche suppose la définition préalable du schéma des relations de la base de données. Il se peut que l application d une règle produit une spécification nécessitant des transformations non systématiques afin que d autres règles de déduction puissent être appliquées. Ceci rend l automatisation d une telle approche très difficilement réalisable. Comparée aux approches existantes, notre approche est plus complète puisqu elle couvre l ensemble des étapes du développement. De plus l ensemble des phases est supporté par des outils. Une approche de développement par raffinement automatique a été mené par MA- TRA, dans le cadre du projet METEOR (ligne 14 du métro parisien), pour le domaine ferroviaire [BUR 99]. L outil supportant cette approche implémente un ensemble de règles de raffinement qui permet l obtention d une spécification finale traduisible en C, C++ ou ADA. Dans [BER 03], une approche de traduction de spécification B0 en C a été présentée. Cette approche est dédiée au développement d applications embarquées dans des cartes à puces. Même si cette approche est très similaire à la notre, elle est plutôt ciblée vers le traitement de données arithmétiques. Par conséquent, les structures de données et de contrôle abstraites et concrètes utilisées sont différentes des nôtres. Dans notre cas, nous utilisons, par exemple, des opérations ensemblistes et conservons le constructeur indéterministe ANY.

35 De B vers JAVA/SQL Conclusion Dans ce rapport, nous avons présenté une démarche systématique de traduction d une spécification B, décrivant une implémentation relationnelle, en code SQL imbriqué dans le langage procédural JAVA. Les spécifications B que nous considérons pour cette traduction sont obtenues par un processus formel et prouvé de raffinement d une spécification B générée elle-même par un processus de traduction formalisé de diagrammes UML dédiés aux systèmes d information. La formalisation de ces deux processus permet de caractériser la forme générique et standard tant des spécifications abstraites B que des spécifications concrètes. Les spécifications B que nous obtenons décrivent les deux aspects complémentaires d une application base de données : le schéma de la base représentant les données de l application et les requêtes SQL associées, les transactions représentant les fonctionnalités. Si la traduction des spécifications B représentant les données se fait en utilisant uniquement le langage SQL, la traduction des transactions, quant à elle, a nécessité l utilisation d un langage hôte offrant les structures de contrôle (JAVA dans notre cas) vers lequel des règles de traduction d expressions et prédicats B ont été définies. L apport principal de la méthode développée est la possibilité de vérifier les contraintes d intégrité dès les premières phases de développement de l application. Grâce aux preuves B, nous assurons que la spécification abstraite des transactions vérifient bien les contraintes et que ces dernières sont préservées tout au long du processus de raffinement. L exemple utilisé dans ce rapport, bien que très simple, couvre les structures de contrôle qui apparaissent dans la grande majorité des applications BD. Des exemples de transactions plus "complexes" peuvent être trouvés dans [MAM 02]. Ces exemples montrent aussi la concision d une spécification par rapport au code : environ 125 lignes de JAVA pour 10 lignes de spécifications B. Notre démarche supporte également les concept de généralisation/spécialisation et de composition. Ce dernier n introduit aucune modification notable ni sur le processus de raffinement, ni sur les règles de traduction vers JAVA/SQL. En effet, sa prise en compte est réalisée par la définition de règles spécifiques de traduction vers B. Par exemple, introduisant essentiellement une dépendance d appels des opérations de base des classes concernées, le concept de composition restreint l ensemble des transactions possibles : dans une composition, une transaction qui supprime le composant sans supprimer les composés est incorrecte. Il est important de noter que bien que l approche aie été définie pour le langage cible JAVA, celle-ci peut s adapter sans modifications majeures à n importe quel langage de programmation procédural comme C ou Pascal. En effet, seules les règles de traduction vers JAVA sont à adapter afin de prendre en considération l aspect syntaxique du langage et également les API offertes par le langage pour l accès à une base de données. Le principe de traduction reste le même. Un des objectifs de ce rapport est de montrer la faisabilité de la traduction d une implémentation B vers du code JAVA/SQL, à partir de règles génériques. L étape suivante est de certifier formellement cette traduction. Pour cela, il faut établir l équivalence sémantique des structures de données et de contrôle entre les deux langages. Notons également que, bien que le code JAVA généré soit facile à maintenir du fait

36 36 2 e soumission à Technique et science informatiques. même qu il soit obtenu par des règles bien précises, des optimisations sur sa taille et son temps d exécution peuvent être envisagées. Par exemple, il serait intéressant de regrouper les méthodes renvoyant les valeurs des clés des différentes tables en une seule méthode paramétrée par la table et le nom de sa clé. Aussi, afin d améliorer la performance du code, il serait éventuellement plus avantageux de regrouper plusieurs requêtes de lecture SQL en une seule, minimisant ainsi le nombre total d accès à la base de données. Ce dernier point requiert la prise en compte de plusieurs critères notamment l architecture de la base de données et sa répartition sur les différents supports de stockage. Ces types d optimisation peuvent être réalisés soit en redéfinissant les règles de traduction des diagrammes UML en spécifications B, ou soit encore en définissant des règles de traduction vers JAVA plus avancées qui prendraient en compte les critères cités précédemment. Afin de rendre notre méthode opérationnelle, nous travaillons actuellement sur l automatisation des différentes étapes constituant notre approche. L outil réalisé jusqu à présent automatise les tâches suivantes : 1) traduction des diagrammes UML en B, 2) raffinement des spécifications B obtenues à la phase précédente, 3) génération du schéma de la base de données et des requêtes de base associées. Notre méthode est dédiée au domaine des bases de données. Toutefois l approche utilisée dans la méthode peut être suivie pour d autres domaines. Il suffit d identifier les caractéristiques du domaine, en particulier le style des spécifications abstraites et des programmes visés, ce qui permet de définir des règles génériques. Un des avantages est alors la possibilité de développer des outils supports de la méthode. 9. Bibliographie [ABR 96] ABRIAL J.-R., The B-Book : Assigning Programs to Meanings, Press Syndicate of the University of Combridge, [Bat 92] BATINI, CERI AND NAVATHE, Conceptual Database Design : An EntityRelationship Approach, The Benjamin/Cummings Publishing Company, [BER 03] BERT D., BOULMÉ S., POTET M., REQUET A., VOISIN L., «Adaptable Translator of B Specifications to Embedded C Programs», FME2003 :International Symposium of Formal Methods Europe, Springer-Verlag, LNCS 2805, September [BUR 99] BURDY L., MEYNADIER J., «Automatic Refinement», FM 99 B Users Group Meeting Applying B in an industrial context : Tools, Lessons and Techniques, 1999, p [COD 70] CODD E., «A Relational Model of Data for Large Shared Data Banks», Communications of the ACM, vol. 13, n o 6, 1970, p [DIG 96] DIGILOG GROUPE STERIA, «Atelier B, Manuel de Référence», BP 16000, Aix-En-Provence Cedex 3 France, [DOL 03] DOLLÉ J., «Traduction de Prédicats B vers JAVA pour le Développement d Applications Bases de Données», Master s thesis, Internship Report of 2 nd level, IIE(CNAM),

37 De B vers JAVA/SQL 37 Evry, France. Available at "s2ec.uni.lu", September [DUP 00] DUPUY S., «Couplage de Notations Semi-Formelles et Formelles pour la Spécification des Systèmes d Information», PhD thesis, Joseph Fourier University, Grenoble, France, September [EDM 92] EDMOND D., Information Modeling, Prentice Hall, [EDM 95] EDMOND D., «Refining Database Systems», J.P. BOWEN AND M.G. HIN- CHEY, Ed., ZUM 95 : The Z Formal Specification Notation, Springer Verlag Lecture Notes in Computer Science, September 1995, p [GOG 00] GOGUEN J., WINKLER T., MESEGUER J., FUTATSUGI K., JOUANNAUD J.-P., «Introducing OBJ», GOGUEN J., Ed., Applications of Algebraic Specification using OBJ, Cambridge, [GUN 93] GUNTHER T., SCHEWE K.-D., WETZEL I., «On the Derivation of Executable Database Programs from Formal Specifications», WOODCOCK J. C. P., LARSEN P. G., Eds., Industrial-Strength Formal Methods, First International Symposium of Formal Methods Europe, Odense, Denmark, vol. 670, p , Springer-Verlag, New York, NY, [HAL 90] HALL A., «Using Z As a Specification Calculus for Object-Oriented Systems», VDM 90 : 3rd International Conference, Kiel, Germany, vol. 428 de LNCS, Springer- Verlag, April [KIM 99] KIM S.-K., CARRINGTON D., «Formalizing the UML Class Diagram Using OBJECT-Z», UML99, vol de LNCS, Springer-Verlag, 1999, p [KIM 02] KIM S.-K., CARRINGTON D., «A Formal Model of the UML Metamodel : The UML State Machine and its Integrity Constraints», ZB2002 : Formal Specification and Development in B and Z. 2nd International Conference of B and Z Users, Grenoble, France, vol de LNCS, Springer-Verlag, January [LAL 00a] LALEAU R., MAMMAR A., «A Generic Process to Refine a B Specification into a Relational Database Implementations», ZB2000 : Formal Specification and Development in Z and B, York, UK, LNCS 1878, September [LAL 00b] LALEAU R., MAMMAR A., «An Overview of a Method and its Support Tool for Generating of B Specifications from UML Notations», The Fifteenth IEEE Int Conference on ASE, September [LAL 01] LALEAU R., MAMMAR A., «An Automatic Generation of B Specifications from Well-defined UML Notations for Database Applications», International Symposium On Programming System, Algiers, Algeria, [LAL 02] LALEAU R., «Conception et Développement Formels d Applications Bases de Données», Habilitation thesis, CEDRIC Laboratory, Evry, France, December [LED 02] LEDANG H., SOUQUIÈRES J., «Contributions for Modelling UML State-Charts in B», Third International Conference on Integrated Formal Methods(IFM2002), May [MAM 01] MAMMAR A., «Développement Formel par Raffinement d Applications Bases de Données Sûres», Revue ISI : Formalimes et Modèles pour les Systèmes d Inforamtion, vol. 6, n o 2, 2001, p [MAM 02] MAMMAR A., «Un Environnement Formel pour le Développement d Applications Bases de Données», PhD thesis, CEDRIC Laboratory, November 2002.

38 38 2 e soumission à Technique et science informatiques. [MAM 04a] MAMMAR A., LALEAU R., «From a B Formal Specification to an Executable Code : Application to the Relational Databases Domain», Submitted to Information & Software Technology Journal, University of Luxembourg. Available at "se2c.uni.lu" [MAM 04b] MAMMAR A., LALEAU R., «UB2SQL : An Integrated Environment Based on UML and the B Formal Method for the Development of Database Applications», [MAR 02] MARCANO-KAMENOFF R., «Spécification Formelle à Objets en UML/OCL et B : Une Approche Transformationnelle», PhD thesis, PRISM Laboratory, December [MEL 93] MELTON J., SIMON A., Understanding the New SQL : A Complete Guide, Morgan Kaufmann, [NGU 98] NGUYEN H.-P., «Dérivation de Spécifications Formelles B à Partir de Spécifications Semi-Formelles», PhD thesis, CEDRIC Laboratory, December [QIA 93] QIAN X., «The Deductive Synthesis of Database Transactions», ACM Transactions on Database Systems, vol. 18, n o 4, 1993, p [SCH 91] SCHEWE K.-D., SCHMIDT J.-W., WETZEL I., «Specification and Refinement in an Integrated Database Application Environment», Proc. VDM Conference 1991, Noordwijkerhout, vol. 551, Springer-Verlag, [TRE 02] TREHARNE H., «Supplementing a UML Development Process with B», FME2002 :International Symposium of Formal Methods Europe, Springer-Verlag, LNCS 2391, July Amel Mammar est ingénieur de l institut d informatique de Tizi-Ouzou (Algérie). Elle est docteur du Conservatoire National des Arts et Métiers (CNAM-Paris). Actuellement assistante scientifique aux projets de recherche de l équipe SE2C de l université du Luxembourg, elle mène des recherches dans le domaine des méthodes formelles pour la vérification d applications e-business et bases de données. Régine Laleau est professeur à l université Paris 12 et membre du laboratoire LACL depuis Auparavant elle était membre du laboratoire CEDRIC du CNAM. Ces activités de recherche concernent notamment l utilisation des méthodes formelles pour la conception et le développement d applications bases de données. Annexe A. Substitutions B Cette annexe présente la sémantique des principales substitutions B utilisées dans ce rapport(voir tableau 5). Les crochets doubles désignent des parties optionnelles. Annexe B. Spécification B du cas d étude Dans cette annexe, nous donnons le spécification B complète de l étude de cas présentée dans ce rapport.

39 De B vers JAVA/SQL 39 Notation B Conditions de définition Signification skip Ne rien modifier x :=E x est une variable Substituer E à x E est une expression PRE P THEN S P est un prédicat S assurer de P et (notée P S) S est une substitution exécuter S IF P THEN S ELSE T P est un prédicat Si P est vrai, exécuter S S et T sont des substitutions sinon exécuter T ANY X WHERE P X est une liste de variables Sélectionner une THEN S P est un prédicat valeur de X qui vérifiele S est une substitution prédicat P et exécuter S [[ u ]] Op [[(v)]] appeler l opération Op avec les paramètres v et affecter son résultat à u S T S et T sont des substitutions exécuter S et T en même temps S ; T S et T sont des substitutions exécuter S puis T Figure 5. Principales substitutions du langage B B.1. Spécification abstraite MACHINE VideoClub SETS Cassette ; Boutique ; Client ; Type Statut={ok, att} DEFINITIONS BasicUpdateNbLibre(ca, nb) = PRE ca cassette nb NAT THEN NbLibre(ca) :=nb ; BasicAddEmprunt(ca, cl, da, st) = PRE ca cassette cl client ca cl / Emprunt da NAT st Type Statut THEN Emprunt := Emprunt {ca cl} DateE := DateE {ca cl da} Statut := Statut {ca cl st} VARIABLES cassette, Titre, NbLibre,Appartient, boutique, NumBo, AdresBo, client, NumCl, NomCl, Emprunt, DateE, Statut INVARIANT cassette Cassette Titre cassette STRING NbLibre cassette NAT boutique boutique Appartient cassette boutique NumBo boutique NAT AdresBo boutique STRING client Client NumCl client NAT NomCl client STRING Emprunt cassette client DateE Emprunt NAT Statut Emprunt Type Statut

40 40 2 e soumission à Technique et science informatiques. INITIALISATION cassette := Titre := NbLibre := Appartient := boutique := NumBo := AdresBo := client := NumCl := NomCl := Emprunt := DateE := Statut := OPERATIONS result LocationCassette(cl, ti, adbo) = PRE cl client adbo ran(adresbo) ti Titre[Appartient 1 [AdresBo 1 [{adbo}]]] Titre[Emprunt 1 [{cl}]] THEN IF ( ( ca.(ca Emprunt 1 [{cl}] DateCourante DateE(ca, cl) > 90))) THEN ANY ca WHERE ca cassette AdresBo(Appartient(ca)) = adbo Titre(ca) =ti THEN IF NbLibre(ca) > 0 THEN BasicAddEmprunt(ca, cl, DateCourante, ok) result :="succes" ELSE BasicAddEmprunt(ca, cl, DateCourante, att) result := "att" IF NbLibre(ca) > 0 THEN BasicUpdateNbLibre(ca, NbLibre(ca) 1) ELSE result :="erreur" ; BasicAddCassette(ca, ti, nb, bo) = PRE ca Cassette cassette ti STRING nb NAT bo boutique THEN cassette := cassette {ca} Titre := Titre {ca ti} NbLibre := NbLibre {ca nb} Appartient := Appartient {ca bo} B.2. Étapes de raffinement B.2.1 Identification des objets REFINEMENT VideoClub Cle REFINES VideoClub DEFINITIONS //L opération BasicUpdateNbLibre reste inchangée BasicUpdateNbLibre(ca, nb) =... //L opération BasicAddEmprunt reste inchagée BasicAddEmprunt(ca, cl, da, st) = VARIABLES//Ajout de la variable NumCa, les autres restent inchangées...,numca INVARIANT NumCa cassette NAT INITIALISATION //les autres variables sont initialisées comme au niveau abstrait... NumCa :=...,

41 De B vers JAVA/SQL 41 OPERATIONS BasicAddCassette(ca, ti, nb, bo) = BEGIN ANY nu WHERE nu NAT ran(numca) THEN cassette := cassette {ca} NumCa := NumCa {ca nu} Titre := Titre {ca Ti} NbLibre := NbLibre {ca nb} Appartient := Appartient {ca bo} B.2.2 Élimination des associations monovaluées REFINEMENT VideoClub Mig REFINES VideoClub Cle DEFINITIONS //L opération BasicUpdateNbLibre reste inchangée BasicUpdateNbLibre(ca, nb) = //L opération BasicAddEmprunt reste inchangée BasicAddEmprunt(ca, cl, da, st) = VARIABLES//Remplacement de Appartient par AppartientMig...,AppartientMig INVARIANT AppartientMig cassette NAT AppartientMig =(Appartient ;NumBo) INITIALISATION //les autres variables sont initialisées comme au niveau abstrait... AppartientMig := OPERATIONS result LocationCassette(cl,ti,adbo) = BEGIN IF ( ( ca.(ca Emprunt 1 [{cl}] DateCourante DateE(ca, cl) > 90))) THEN ANY ca WHERE ca cassette AdresBo((AppartientMig ;NumBo 1 )(ca)) = adbo Titre(ca) =ti THEN IF NbLibre(ca) > 0 THEN BasicAddEmprunt(ca, cl, DateCourante, ok) result :="succes" ELSE BasicAddEmprunt(ca, cl, DateCourante, att) result :="att" IF NbLibre(ca) > 0 THEN BasicUpdateNbLibre(ca, NbLibre(ca) 1) ELSE result :="erreur" ; BasicAddCassette(ca, ti, nb, bo) = BEGIN ANY nu WHERE nu NAT ran(numca) THEN cassette := cassette {ca} NumCa := NumCa {ca nu} Titre := Titre {ca Ti} NbLibre := NbLibre {ca nb}

42 42 2 e soumission à Technique et science informatiques. AppartientMig := AppartientMig {ca NumBo(bo)} B.2.3 Élimination des associations multivaluées REFINEMENT VideoClub Asso REFINES VideoClub Mig DEFINITIONS //L opération BasicUpdateNbLibre reste inchangée BasicUpdateNbLibre(ca, nb) = BasicAddEmprunt(ca, cl, da, st) = BEGIN Emprunt := Emprunt {ca cl} EmpruntCa := EmpruntCa {ca cl NumCa(ca)} EmpruntCl := EmpruntCl {ca cl NumCl(cl)} DateE := DateE {ca cl da} Statut := Statut {ca cl st} VARIABLES//Ajout de deux variables : EmpruntCa et EmpruntCl..., EmpruntCa, EmpruntCl INVARIANT EmpruntCa = Emprunt (prj 1(cassette, client) ;NumCa) EmpruntCl = Emprunt (prj 2(cassette, client) ;NumCl) EmpruntCa EmpruntCl Emprunt NAT NAT INITIALISATION //les autres variables sont initialisées comme au niveau abstrait... EmpruntCa, EmpruntCl :=, //Les opérations restant inchangées, elles peuvent ne pas être reprises dans ce composant B.2.4 Passage d un modèle fonctionnel à un modèle ensembliste REFINEMENT VideoClub Struct REFINES VideoClub Asso DEFINITIONS DateE 1 = (T Emprunt ;prj 1(NAT NAT NAT, Type Statut) ; prj 2(NAT NAT, NAT)) ; NumCl 1 = (T Client ; prj 1(NAT, STRING)) ; NumBo 1 = (T Boutique ; prj 1(NAT, STRING)) ; AdresBo 1 = (T Boutique ; prj 2(NAT, STRING)) ; NumCa 1 = (T Cassette ; prj 1(NAT NAT NAT, NAT) ; prj 1(NAT NAT, NAT) ; prj 1(NAT, NAT)) ;

43 De B vers JAVA/SQL 43 Titre 1 = (T Cassette ; prj 1(NAT NAT NAT, NAT) ;prj 1(NAT NAT, NAT) ; prj 2(NAT, NAT)) ; NbLibre 1 = (T Cassette ;prj 1(NAT NAT NAT, NAT) ; prj 2(NAT NAT, NAT)) ; AppartientMig 1 = (T Cassette ;prj 2(NAT NAT NAT, NAT)) ; BasicUpdateNbLibre(ca, nb) = BEGIN T Cassette := NumCa 1 Titre 1 (NbLibre 1 {ca nb}) AppartientMig 1 ; BasicAddEmprunt(ca, cl, da, st)== BEGIN Emprunt := Emprunt {ca cl} T Emprunt := T Emprunt {ca cl (NumCa 1(ca) NumCl 1(cl) da st)} VARIABLES cassette, boutique, client, Emprunt, T Cassette, T Boutique, T Client, T Emprunt INVARIANT T Cassette cassette NAT STRING NAT NAT T Cassette = NumCa Titre NbLibre AppartientMig T Boutique boutique NAT STRING T Boutique = NumBo AdresBo T Client Client NAT STRING T Client = NumCl NomCl T Emprunt Emprunt NAT NAT NAT Type Statut T Emprunt = EmpruntCa EmpruntCl DateE Statut INITIALISATION cassette := boutique := client := Emprunt := T Cassette := T Boutique := T Client := T Emprunt := OPERATIONS result LocationCassette(cl,ti,adbo)= BEGIN IF ( ( ca.(ca Emprunt 1 [{cl}] DateCourante DateE 1(ca, cl) > 90))) THEN ANY ca WHERE ca cassette AdresBo 1((AppartientMig 1 ;NumBo 1 1 )(ca)) = adbo Titre1(ca) =ti THEN IF NbLibre 1(ca) > 0 THEN BasicAddEmprunt(ca, cl, DateCourante, ok) result :="succes" ELSE BasicAddEmprunt(ca, cl, DateCourante, att) result :="att" IF NbLibre 1(ca) > 0 THEN BasicUpdateNbLibre(ca, NbLibre 1(ca) 1) ELSE result :="erreur" ; BasicAddCassette(ca, ti, nb, bo) = BEGIN ANY nu WHERE nu NAT ran(numca 1) THEN cassette := cassette ca T Cassette := T Cassette {ca (nu ti nb NumBo 1(Bo))}

44 44 2 e soumission à Technique et science informatiques. B.2.5 Implémentation des données et opérations de base B Machines importées 1) La machine Boutique Rel MACHINE Boutique Rel VARIABLES Table Boutique INVARIANT Table Boutique struct(numbo : NAT, AdresBo : STRING) INITIALISATION Table Boutique := 2) La machine Client Rel MACHINE Client Rel VARIABLES Table Client INVARIANT Table Client struct(numcl : NAT, NomCl : STRING) INITIALISATION Table Client := 3) La machine Cassette Rel MACHINE Cassette Rel VARIABLES Table Cassette INVARIANT Table Cassette struct(numca : NAT, Titre : STRING, NbLibre : NAT, AppartientMig : NAT) INITIALISATION Table Cassette := OPERATIONS InsertCassette(x 1, x 2, x 3, x 4)= PRE x 1 NAT x 2 NAT x 3 NAT x 4 NAT THEN Table Cassette := Table Cassette {rec(x 1, x 2, x 3, x 4)} ; UpdateNbLibre(x 1, x 2)= PRE x 1 NAT x 2 NAT THEN ANY xx WHERE xx Table Cassette xx NumCa = x 1 THEN Table Cassette := Table Cassette {xx} {rec(xx NumCa, xx Titre, x 2, xx AppartientMig)} 4) La machine Emprunt Rel MACHINE Emprunt Rel SETS Type Statut = {ok, att} VARIABLES Table Emprunt INVARIANT Table Emprunt struct(empruntca : NAT, EmpruntCl : NAT, DateE : NAT, Statut : Type Statut) INITIALISATION Table Emprunt :=

45 De B vers JAVA/SQL 45 OPERATIONS InsertEmprunt(x 1, x 2, x 3, x 4)= PRE x 1 NAT x 2 NAT x 3 NAT x 4 Type Statut THEN Table Emprunt := Table Emprunt {rec(x 1, x 2, x 3, x 4)} 5) La machine Utility MACHINE Utility EXTS Client Rel, Boutique Rel, Cassette Rel, Emprunt Rel DEFINITIONS Emprunt 1 = UNION yy.(yy Table Emprunt {yy EmpruntCa yy EmpruntCl}) ; DateE 1 = UNION yy.(yy Table Emprunt {yy EmpruntCa yy EmpruntCl yy DateE}) ; cassette = UNION yy.(yy Table Cassette {yy NumCa}) ; Titre 1 = UNION yy.(yy Table Cassette {yy NumCa yy Titre}) ; NbLibre 1 = UNION yy.(yy Table Cassette {yy NumCa yy NbLibre}) ; AppartientMig 1 = UNION yy.(yy Table Cassette {yy NumCa yy AppartientMig}) ; AdresBo 1 = UNION zz.(zz Table Boutique {zz NumBo zz AdresBo}) OPERATIONS resleftarrow ClientEnRegle(cl)= PRE cl NAT THEN IF ( ( ca.(ca Emprunt({cl}) DateCourante DateE 1(ca, cl) > 90))) THEN res :=TRUE ELSE res :=FALSE ; cas RenvoiCassetteTitre(ti,adbo) = PRE ti NAT adbo NAT THEN ANY ca WHERE ca Cassette AdresBo 1(AppartientMig 1(ca)) = adbo Titre 1(ca) =ti THEN cas :=ca ; res CopieDisponible(ca)= PRE ca NAT THEN IF (NbLibre 1(ca) > 0) THEN res :=TRUE ELSE res :=FALSE ; val param NouvelleValNbLibre(ca)= PRE ca NAT THEN val param := NbLibre 1(ca) 1

46 46 2 e soumission à Technique et science informatiques. B Implémentation des transactions IMPLEMENTATION VideoClub Imp REFINES VideoClub Struct IMPORTS Utility VALUES //Valuation des ensembles abstraits Cassette=NAT ; Boutique=NAT ; Client=NAT INVARIANT (T Cassette ;prj 1(NAT STRING NAT, NAT) ;prj 1(NAT STRING, NAT) ; prj 1(NAT, STRING)) = id(cassette) (x 1, x 2, x 3, x 4).(x 1 (x 1 x 2 x 3 x 4) T Cassette rec(x 1, x 2, x 3, x 4) Table Cassette) (x 1, x 2, x 3, x 4).(rec(x 1, x 2, x 3, x 4) Table Cassette x1 (x 1 x 2 x 3 x 4) T Cassette) (T Boutique ;prj 1(NAT, STRING)) = id(boutique) (x 1, x 2).(x 1 (x 1 x 2) T Boutique rec(x 1, x 2) Table Boutique) (x 1, x 2).(rec(x 1, x 2) Table Boutique x 1 (x 1 x 2) T Boutique) (T Client ;prj 1(NAT, STRING)) = id(client) (x 1, x 2).(x 1 (x 1 x 2) T Client rec(x 1, x 2) Table Client) (x 1, x 2).(rec(x 1, x 2) Table Client x1 (x 1 x 2) T Client) (x 1, x 2, x 3, x 4).(x 1 x 2 (x 1 x 2 x 3 x 4) T Emprunt rec(x 1, x 2, x 3, x 4) Table Emprunt) (x 1, x 2, x 3, x 4).(rec(x 1, x 2, x 3, x 4) Table Emprunt x 1 x 2 (x 1 x x 3 x 4) T Emprunt) OPERATIONS result LocationCassette(cl,ti,adbo) = BEGIN VAR val pred 1, ca, val pred 2, val param IN val pred1 ClientEnRegle(cl) ; ca RenvoiCassetteTitre(ti, adbo) ; val pred 2 CopieDisponible(ca) ; val param NouvelleValNbLibre(ca) ; IF val pred 1 = TRUE THEN IF val pred 2 = TRUE THEN InsertEmprunt(ca, cl, DateCourante, ok) ; result := succ ELSE InsertEmprunt(ca, cl, DateCourante, att) ; result := att ; IF val pred 2 = TRUE THEN UpdateNbLibre(ca, val param) ELSE result :="erreur" ; BasicAddCassette(ca, ti, nb, bo) = BEGIN Insert Cassette(ca, ti, nb, bo)

47 De B vers JAVA/SQL 47 Annexe C. Code JAVA Cette section décrit le code JAVA généré pour le cas d étude présenté dans ce rapport. C.1. La Classe Boutique ÑÔÓÖØ Ú º Õº ÔÙ ÓÙØ ÕÙ ß ÔÖ Ú Ø ÓÒÒ Ø ÓÒ ÓÒÒ» Ö Ø ÓÒ ³ÙÒ Ò Ø Ò» ÔÙ ÓÙØ ÕÙ ÓÒÒ Ø ÓÒ ÓÒÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß Ø ºÓÒÒ ÓÒÒ» Ê ØÓÙÖÒ Ö ÓÒÒ Ü ÓÒ Ó» ÔÙ ÓÒÒ Ø ÓÒ Ø ÓÒÒ Ø ÓÒ µ ß Ö ØÙÖÒ ÓÒÒ C.2. La Classe Cassette ÑÔÓÖØ Ú º Õº ÔÙ ØØ ß ÔÖ Ú Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÍÔ Ø Æ Ä Ö ÔÖ Ú Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÊ Æ Ä Ö ÔÖ Ú Ø ÓÒÒ Ø ÓÒ ÓÒÒ ÔÙ ØØ ÓÒÒ Ø ÓÒ ÓÒÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß Ø ºÓÒÒ ÓÒÒ ØÑØÍÔ Ø Æ Ä Ö ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ ÙÔ Ø ØØ Ø Æ Ä Ö ÏÀ Ê ÆÙÑ µ ØÑØÊ Æ Ä Ö ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ø Æ Ä Ö ÖÓÑ ØØ Û Ö ÆÙÑ µ ÔÙ ÓÒÒ Ø ÓÒ Ø ÓÒÒ Ø ÓÒ µ ß Ö ØÙÖÒ ÓÒÒ

48 48 2 e soumission à Technique et science informatiques. ÔÙ ÚÓ ÍÔ Ø Æ Ä Ö ÒØ ÒÙ ÒØ Ò µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ØÑØÍÔ Ø Æ Ä Ö º ØÁÒØ ½ ÒÙµ ØÑØÍÔ Ø Æ Ä Ö º ØÁÒØ ¾ Ò µ ØÑØÍÔ Ø Æ Ä Ö º Ü ÙØ ÍÔ Ø µ ÔÙ ÓÓ Ò ÓÔ ÔÓÒ ÒØ ÒÙµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ØÑØÊ Æ Ä Ö º ØÁÒØ ½ ÒÙµ Ê ÙØË Ø Ö ØÑØÊ Æ Ä Ö º Ü ÙØ ÉÙ ÖÝ µ Ö ºÒ ÜØ µ ÒØ ÜÔ½ Ö º ØÁÒØ ½µ Ö ØÙÖÒ ÜÔ½ ¼µ ÔÙ ÒØ ÆÓÙÚ Î Æ Ä Ö ÒØ ÒÙµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ØÑØÊ Æ Ä Ö º ØÁÒØ ½ ÒÙµ Ê ÙØË Ø Ö ØÑØÊ Æ Ä Ö º Ü ÙØ ÉÙ ÖÝ µ Ö ºÒ ÜØ µ Ö ØÙÖÒ Ö º ØÁÒØ ½µ¹½µ C.3. La Classe Client ÑÔÓÖØ Ú º Õº ÔÙ ÒØß ÔÖ Ú Ø ÓÒÒ Ø ÓÒ ÓÒÒ ÔÙ ÒØ ÓÒÒ Ø ÓÒ ÓÒÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß Ø ºÓÒÒ ÓÒÒ ÔÙ ÓÒÒ Ø ÓÒ Ø ÓÒÒ Ø ÓÒ µ ß Ö ØÙÖÒ ÓÒÒ C.4. La Classe Emprunt ÑÔÓÖØ Ú º Õº ÑÔÓÖØ Î ØºÎ ØÓÖË Ø ÔÙ ÑÔÖÙÒØß

49 De B vers JAVA/SQL 49 ÔÖ Ú Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÁÒ ÖØ ÔÖ Ú Ø Ø Ø ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÊ Ø ÔÖ Ú Ø ÓÒÒ Ø ÓÒ ÓÒÒ ÔÙ ÑÔÖÙÒØ ÓÒÒ Ø ÓÒ ÓÒÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß Ø ºÓÒÒ ÓÒÒ ØÑØÁÒ ÖØ ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ò ÖØ ÒØÓ ÑÔÖÙÒØ Ú Ù µ µ ØÑØÊ Ø ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ø Ø ÖÓÑ ÑÔÖÙÒØ Û Ö ÑÔÖÙÒØ Ò ÑÔÖÙÒØ µ ÔÙ ÓÒÒ Ø ÓÒ Ø ÓÒÒ Ø ÓÒ µ ß Ö ØÙÖÒ ÓÒÒ ÔÙ ÚÓ ÁÒ ÖØ ÑÔÖÙÒØ ÒØ ÒØ ÓÓ Ò Ø Ø µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ØÑØÁÒ Öغ ØÁÒØ ½ µ ØÑØÁÒ Öغ ØÁÒØ ¾ µ ØÑØÁÒ Öغ Ø Ø µ ØÑØÁÒ Öغ Ø ÓÓ Ò Øµ ØÑØÁÒ Öغ Ü ÙØ ÍÔ Ø µ ÔÙ Ø ÑÔÖÙÒØÊ Ø ÒØ ÒØ µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ÔÔ Ü ÔØ ÓÒß ØÑØÊ Ø º ØÁÒØ ½ µ ØÑØÊ Ø º ØÁÒØ ¾ µ Ê ÙØË Ø Ö ØÑØÊ Ø º Ü ÙØ ÉÙ ÖÝ µ Ö ºÒ ÜØ µ Ö ØÙÖÒ Ö º Ø Ø ½µ ÔÙ Ê ÙØË Ø Ø ÒØ Î ØÓÖË Ø µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ß ËØÖ Ò Ô Ö Ñ Ò Û ËØÖ Ò µ ÒØ ËØÖ Ò Ö Õ Ø ÑÔÖÙÒØ ÖÓÑ ÑÔÖÙÒØ Û Ö ÑÔÖÙÒØ ÁÆ ÓÖ ¼ º Þ µ¹½ µ Ö Õ Ö Õ Ö Õ Ö Õ µ ÈÖ Ô Ö ËØ Ø Ñ ÒØ ØÑØÄ Ö ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ö Õµ ÓÖ ¼ º Þ µ µ ØÑØÄ Ö º ØÇ Ø ½ ºÚ ØÓÖ µº Ñ ÒØ Ø µµ Ê ÙØË Ø Ö ÙØ ØÑØÄ Ö º Ü ÙØ ÉÙ ÖÝ µ Ö ØÙÖÒ Ö ÙØ

50 50 2 e soumission à Technique et science informatiques. C.5. La Classe ClientEnRetard ÑÔÓÖØ Ú º Õº ÑÔÓÖØ Ú ºÙØ º Ò Ö ÑÔÓÖØ Î ØÓÖË Ø ÔÙ ÒØ ÒÊ Ø Ö ß ÓÒÒ Ø ÓÒ ÓÒÒ ÑÔÖÙÒØ ÑÔÖÙÒØ ÔÙ ÒØ ÒÊ Ø Ö ÑÔÖÙÒØ ÑÔÖÙÒص ß Ø ºÓÒÒ ÑÔÖÙÒغ Ø ÓÒÒ Ø ÓÒ µ Ø º ÑÔÖÙÒØ ÑÔÖÙÒØ» ÇÔ Ö Ø ÓÒ Ø Ø ÒØ ÙÒ ÒØ Ø Ò Ö Ø Ö» ÔÙ ÓÓ Ò Î ÒØ µ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ÔÔ Ü ÔØ ÓÒß ÓÓ Ò ØÖÓÙÚ» ÓÒ ØÖÙØ ÓÒ ³ Ò Ñ ß» Î ØÓÖË Ø ½ Ò Û Î ØÓÖË Ø µ ½º µ Î ØÓÖË Ø Ò Û Î ØÓÖË Ø ÑÔÖÙÒغ Ø ÒØ ½µµ ÒØ ÓÖ ¼ º Þ µ ²² ØÖÓÙÚ µ µß ÒØ Ö Ø ÁÒØ Öµ ºÚ ØÓÖ µµº Ñ ÒØ Ø µµº ÒØÎ Ù µ Ú ºÙØ º Ò Ö Ò Û Ú ºÙØ º Ö ÓÖ Ò Ò Ö µ Ú º Õº Ø Ø ÑÔÖÙÒغ ÑÔÖÙÒØÊ Ø Ö Ø µ º ØÌ Ñ Ø µ Ú ºÙØ º Ò Ö Ø ÓÙÖ ÒØ Ò Öº ØÁÒ Ø Ò µ º Ò Öº Ì ¼µ º ÓÖ Ø ÓÙÖ ÒØ µµ ØÖÓÙÚ ØÖÙ Ö ØÙÖÒ ØÖÓÙÚ C.6. La Classe RenvoieCassette ÑÔÓÖØ Ú º Õº ÔÙ Ê ÒÚÓ ØØ ß ÓÒÒ Ø ÓÒ ÓÒÒ ÔÙ Ê ÒÚÓ ØØ ÓÒÒ Ø ÓÒ ÓÒµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒß

51 De B vers JAVA/SQL 51 Ø ºÓÒÒ ÓÒ ÔÙ ÒØ Î ËØÖ Ò Ø ËØÖ Ò Óµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ÔÔ Ü ÔØ ÓÒß ÓÓ Ò ØÖÓÙÚ ÈÖ Ô Ö ËØ Ø Ñ ÒØ Ö ÕÙ Ø ÓÒÒºÔÖ Ô Ö ËØ Ø Ñ ÒØ Ø ºÆÙÑ ÖÓÑ ØØ Û Ö Ø Óº Ö Ó ÖÓÑ ÓÙØ ÕÙ Ó Û Ö ÓºÆÙÑ Ó º ÔÔ ÖØ Òص Ò ºØ ØÖ µ Ö ÕÙ Ø º ØËØÖ Ò ½ Óµ Ö ÕÙ Ø º ØËØÖ Ò ¾ Ø µ Ê ÙØË Ø Ö Ö ÕÙ Ø º Ü ÙØ ÉÙ ÖÝ µ Ö ºÒ ÜØ µ Ö ØÙÖÒ Ö º ØÁÒØ ½µ C.7. La Classe traitant les exceptions AppException ÔÙ Ò ÔÔ Ü ÔØ ÓÒ ÜØ Ò ÊÙÒØ Ñ Ü ÔØ ÓÒ ß ÔÙ ÔÔ Ü ÔØ ÓÒ ËØÖ Ò Ñ µ ß ÙÔ Ö Ñ µ ËÝ Ø ÑºÓÙغÔÖ ÒØÒ Ñ µ C.8. La Classe représentant la transaction LocationCassette ÑÔÓÖØ Ú º Õº ÑÔÓÖØ Ú ºÙØ º Ò Ö ÔÙ ËÝ Ø Ñ ß ÔÖ Ú Ø ÑÔÖÙÒØ ÑÔÖÙÒØ ÔÖ Ú Ø ØØ ØØ ÔÖ Ú Ø ÓÙØ ÕÙ ÓÙØ ÕÙ ÔÖ Ú Ø ÒØ ÒØ ÔÖ Ú Ø ÒØ ÒÊ Ø Ö ÒØ ÒÖ Ø Ö ÔÖ Ú Ø Ê ÒÚÓ ØØ Ö ÒÚÓ ØØ ÔÖ Ú Ø ËÝ Ø Ñ Ý Ø Ñ ÓÒÒ Ø ÓÒ ÓÒÒ ÔÙ ËÝ Ø Ñ Ê ÒÚÓ ØØ Ö ÒÚÓ ØØ ÒØ ÒÊ Ø Ö ÒØ ÒÖ Ø Ö ÑÔÖÙÒØ ÑÔÖÙÒØ ØØ ØØ ÓÙØ ÕÙ

52 52 2 e soumission à Technique et science informatiques. ÓÙØ ÕÙ ÒØ Òص ß Òغ Ø ÓÒÒ Ø ÓÒ µ ÑÔÖÙÒغ Ø ÓÒÒ Ø ÓÒ µ ØØ º Ø ÓÒÒ Ø ÓÒ µ Òغ Ø ÓÒÒ Ø ÓÒ µ ØØ º Ø ÓÒÒ Ø ÓÒ µ ÓÙØ ÕÙ º Ø ÓÒÒ Ø ÓÒ µµ Ø ÖÓÛ Ò Û ÔÔ Ü ÔØ ÓÒ Ä Ò Ø Ò Ò³ÙØ ÒØ Ô Ñ Ñ ÓÒÒ Ü ÓÒ Ù ÖÚ ÙÖ µ Ø ºÓÒÒ Òغ Ø ÓÒÒ Ø ÓÒ µ Ø º ÒØ ÒØ Ø º ÑÔÖÙÒØ ÑÔÖÙÒØ Ø º ØØ ØØ Ø º ÓÙØ ÕÙ ÓÙØ ÕÙ Ø º ÒØ ÒÖ Ø Ö ÒØ ÒÖ Ø Ö Ø ºÖ ÒÚÓ ØØ Ö ÒÚÓ ØØ» ÇÔ Ö Ø ÓÒ ³ ÓÙØ ³ÙÒ ÑÔÖÙÒØ» ÔÙ ËØÖ Ò ÄÓ Ø ÓÒ ØØ ÒØ ËØÖ Ò Ø ËØÖ Ò Óµ Ø ÖÓÛ ËÉÄ Ü ÔØ ÓÒ ÔÔ Ü ÔØ ÓÒß ØÖÝ ß ËØÖ Ò Ö ÔÓÒ ÓÓ Ò Ú ÔÖ ½ ÒØ ÒÖ Ø Ö ºÎ µ ÒØ Ö ÒÚÓ ØØ ºÎ Ø Óµ ÓÓ Ò Ú ÔÖ ¾ ØØ º ÓÔ ÔÓÒ µ ÒØ Ú Ô Ö Ñ ØØ ºÆÓÙÚ Î Æ Ä Ö µ Ú ÔÖ ½µß Ú ºÙØ º Ò Ö Ò Öº ØÁÒ Ø Ò µ Ú º Õº Ø Ø ÓÙÖ ÒØ Ò Û Ú º Õº Ø º ØÌ Ñ µº ØÌ Ñ µµ Ú ÔÖ ¾µß ÑÔÖÙÒغÁÒ ÖØ ÑÔÖÙÒØ ØÖÙ Ø ÓÙÖ ÒØ µ Ö ÔÓÒ Ù ß ÑÔÖÙÒغÁÒ ÖØ ÑÔÖÙÒØ Ø ÓÙÖ ÒØ µ Ö ÔÓÒ ØØ Ú ÔÖ ¾µ ØØ ºÍÔ Ø Æ Ä Ö Ú Ô Ö Ñµ ÓÒÒºÓÑÑ Ø µ ÓÒÒºÓ µ Ö ÔÓÒ ÖÖ ÙÖ Ö ØÙÖÒ Ö ÔÓÒ Ø Ü ÔØ ÓÒ µ ß ËÝ Ø ÑºÓÙغÔÖ ÒØ µ

53 De B vers JAVA/SQL 53 ÓÒÒºÖÓ µ Ö ØÙÖÒ ØÖ Ò Ø ÓÒ ÒÓÒ Ü ÙØ µ