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

Dimension: px
Commencer à balayer dès la page:

Download "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 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.

Introduction aux bases de données

Introduction aux bases de données 1/73 Introduction aux bases de données Formation continue Idir AIT SADOUNE idir.aitsadoune@supelec.fr École Supérieure d Électricité Département Informatique Gif sur Yvette 2012/2013 2/73 Plan 1 Introduction

Plus en détail

1. Objectifs de la Modélisation. Dériver le schéma de la BD. Élaborer un modèle conceptuel. Modélisation E/R des Données

1. Objectifs de la Modélisation. Dériver le schéma de la BD. Élaborer un modèle conceptuel. Modélisation E/R des Données . Objectifs et principes Modélisation E/R des Données 2. Le modèle Entité-Association (E/R) 3. Passage au relationnel 4. Conclusion. Objectifs de la Modélisation Permettre une meilleure compréhension Le

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Cours Base de données relationnelles. M. Boughanem, IUP STRI Cours Base de données relationnelles 1 Plan 1. Notions de base 2. Modèle relationnel 3. SQL 2 Notions de base (1) Définition intuitive : une base de données est un ensemble d informations, (fichiers),

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

Faculté de Sciences Économiques et de Gestion. Bases de données. Maîtrise de Sciences Économiques Année 2001-2002 Jérôme Darmont

Faculté de Sciences Économiques et de Gestion. Bases de données. Maîtrise de Sciences Économiques Année 2001-2002 Jérôme Darmont Faculté de Sciences Économiques et de Gestion Bases de données Maîtrise de Sciences Économiques Année 2001-2002 Jérôme Darmont http://eric.univ-lyon2.fr/~jdarmont/ Plan du cours I. Introduction II. Le

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet CNAM UV 19357 Année 2003-2004 David Delahaye David.Delahaye@cnam.fr Conception et Développement Orientés Objets Cours 1 : Introduction 1 Présentation de la valeur Ce cours s adresse à toute personne ayant

Plus en détail

UML et les Bases de Données

UML et les Bases de Données CNAM UML et les Bases de Données UML et les Bases de Données. Diagramme de classes / diagramme d objets (UML)...2.. Premier niveau de modélisation des données d une application...2.2. Les éléments de modélisation...2.2..

Plus en détail

Partie I : Automates et langages

Partie I : Automates et langages 2 Les calculatrices sont interdites. N.B. : Le candidat attachera la plus grande importance à la clarté, à la précision et à la concision de la rédaction. Si un candidat est amené à repérer ce qui peut

Plus en détail

Correction de programmes : Logique de Hoare

Correction de programmes : Logique de Hoare 16 juillet 2009 Logique et informatique Vis-à-vis de l informatique la logique a au moins 2 rôles : 1 Externe et théorique (fondements de l informatique - Électif en S4) : Logique comme méta-informatique

Plus en détail

Conception des bases de données : Modèle Entité-Association

Conception des bases de données : Modèle Entité-Association Conception des bases de données : Modèle Entité-Association La modélisation d un problème, c est-à-dire le passage du monde réel à sa représentation informatique, se définit en plusieurs étapes pour parvenir

Plus en détail

Chapitre 3 LE MODELE RELATIONNEL

Chapitre 3 LE MODELE RELATIONNEL Chapitre 3 LE MODELE RELATIONNEL Le modèle relationnel a été inventé en 1960 et a fait l'objet de très nombreuses recherches qui ont débouché sur la réalisation et commercialisation de SGBDs relationnels.

Plus en détail

Rappel sur les bases de données

Rappel sur les bases de données Rappel sur les bases de données 1) Généralités 1.1 Base de données et système de gestion de base de donnés: définitions Une base de données est un ensemble de données stockées de manière structurée permettant

Plus en détail

OCL - Object Constraint Language

OCL - Object Constraint Language OCL - Object Constraint Language Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon SIMA - OCL - Object

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Modèle relationnel Création et modification des relations en SQL

Modèle relationnel Création et modification des relations en SQL Modèle relationnel Création et modification des relations en SQL ENT - Clé sql2009 BD - Mírian Halfeld-Ferrari p. 1 Insertion dans une relation Pour insérer un tuple dans une relation: insert into Sailors

Plus en détail

Chapitre 4 Modélisation et Conception de BD

Chapitre 4 Modélisation et Conception de BD Pourquoi une modélisation préalable? Chapitre 4 Modélisation et Conception de BD Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Stockage physique Cohérence/intégrité

Plus en détail

Les références et la mémoire

Les références et la mémoire Chapitre 3 Les références et la mémoire 3.1 Introduction En Java, pour déclarer une variable, il faut donner son nom, précédé du type qu on souhaite lui attribuer. Ces types peuvent être des types primitifs

Plus en détail

Construction formelle de logiciels

Construction formelle de logiciels Construction formelle de logiciels La méthode B J. Christian Attiogbé Novembre 2008, maj 11/2009, 10/2010 J. Christian Attiogbé (Novembre 2008, maj 11/2009, Construction 10/2010) formelle de logiciels

Plus en détail

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

Plus en détail

Langage SQL : créer et interroger une base

Langage SQL : créer et interroger une base Langage SQL : créer et interroger une base Dans ce chapitre, nous revenons sur les principales requêtes de création de table et d accès aux données. Nous verrons aussi quelques fonctions d agrégation (MAX,

Plus en détail

Chapitre 5 LE MODELE ENTITE - ASSOCIATION

Chapitre 5 LE MODELE ENTITE - ASSOCIATION Chapitre 5 LE MODELE ENTITE - ASSOCIATION 1 Introduction Conception d une base de données Domaine d application complexe : description abstraite des concepts indépendamment de leur implémentation sous

Plus en détail

OpenPaaS Le réseau social d'entreprise

OpenPaaS Le réseau social d'entreprise OpenPaaS Le réseau social d'entreprise Spécification des API datastore SP L2.3.1 Diffusion : Institut MinesTélécom, Télécom SudParis 1 / 12 1OpenPaaS DataBase API : ODBAPI...3 1.1Comparaison des concepts...3

Plus en détail

Tableaux dynamiques: vecteurs

Tableaux dynamiques: vecteurs Tableaux dynamiques: vecteurs Pour pallier les défauts inhérents à la rigidité des tableaux de taille fixe (built-in array), la librairie (générique) standard 1 de C++ fournit un type de donnée 2 dénommée

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Traduction des Langages : Le Compilateur Micro Java

Traduction des Langages : Le Compilateur Micro Java BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant

Plus en détail

Bases de données. Jean-Yves Antoine. VALORIA - Université François Rabelais Jean-Yves.Antoine@univ-tours.fr. L3 S&T mention Informatique

Bases de données. Jean-Yves Antoine. VALORIA - Université François Rabelais Jean-Yves.Antoine@univ-tours.fr. L3 S&T mention Informatique Bases de données Jean-Yves Antoine VALORIA - Université François Rabelais Jean-Yves.Antoine@univ-tours.fr L3 S&T mention Informatique Bases de Données IUP Vannes, UBS J.Y. Antoine 1 Bases de données SGBD

Plus en détail

Définition de contraintes. c Olivier Caron

Définition de contraintes. c Olivier Caron Définition de contraintes 1 Normalisation SQL-92 Les types de contraintes 1 Les types de contraintes Normalisation SQL-92 Les contraintes de domaine définissent les valeurs prises par un attribut. 1 Les

Plus en détail

Une extension pour RDF/RDFS utilisant des relations procédurales

Une extension pour RDF/RDFS utilisant des relations procédurales Une extension pour RDF/RDFS utilisant des relations procédurales Jean-François Baget * * INRIA Sophia-Antipolis & LIRMM(CNRS - UM2) LIRMM, 161 rue Ada, 34392 Montpellier Cedex 5 baget@lirmm.fr RÉSUMÉ.

Plus en détail

Traduction entre niveaux d abstraction pour des applications de bases de données

Traduction entre niveaux d abstraction pour des applications de bases de données UNIVERSITE LIBRE DE BRUXELLES Faculté des Sciences Appliquées Année académique 2001-2002 Traduction entre niveaux d abstraction pour des applications de bases de données DIRECTEUR DE MEMOIRE : Prof. E.

Plus en détail

Langage SQL (1) 4 septembre 2007. IUT Orléans. Introduction Le langage SQL : données Le langage SQL : requêtes

Langage SQL (1) 4 septembre 2007. IUT Orléans. Introduction Le langage SQL : données Le langage SQL : requêtes Langage SQL (1) Sébastien Limet Denys Duchier IUT Orléans 4 septembre 2007 Notions de base qu est-ce qu une base de données? SGBD différents type de bases de données quelques systèmes existants Définition

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

λ-calcul et typage Qu est-ce qu une fonction?

λ-calcul et typage Qu est-ce qu une fonction? λ-calcul et typage Nicolas Barnier, Pascal Brisset ENAC Avril 2009 Nicolas Barnier, Pascal Brisset (ENAC) λ-calcul et typage Avril 2009 1 / 1 Qu est-ce qu une fonction? Classiquement Pas de notation uniforme/standard

Plus en détail

Algorithmique et Analyse d Algorithmes

Algorithmique et Analyse d Algorithmes Algorithmique et Analyse d Algorithmes L3 Info Cours 11 : Arbre couvrant Prétraitement Benjamin Wack 2015-2016 1 / 32 La dernière fois Rappels sur les graphes Problèmes classiques Algorithmes d optimisation

Plus en détail

Les procédures stockées et les fonctions utilisateur

Les procédures stockées et les fonctions utilisateur Les procédures stockées et les fonctions utilisateur Z Grégory CASANOVA 2 Les procédures stockées et les fonctions utilisateur [08/07/09] Sommaire 1 Introduction... 3 2 Pré-requis... 4 3 Les procédures

Plus en détail

Chapitre 2 Modélisation de bases de données

Chapitre 2 Modélisation de bases de données Pourquoi une modélisation préalable? Chapitre 2 Modélisation de bases de données 1. Première étape : le modèle conceptuel Eemple : le modèle Entités-Associations (E/A) 2. Deuième étape : le modèle Traduction

Plus en détail

METHODE B Formation niveau 1. juin 2005

METHODE B Formation niveau 1. juin 2005 METHODE B Formation niveau 1 juin 2005 Table des matières introduction à B méthode formelle avec preuve utilisation de B fondements apports notions de B modules B composants B machines abstraites raffinements

Plus en détail

Bases de données. Yamine Aït-Ameur ENSEEIHT yamine@enseeiht.fr. Christophe Garion ISAE-SUPAERO christophe.garion@isae-supaero.fr.

Bases de données. Yamine Aït-Ameur ENSEEIHT yamine@enseeiht.fr. Christophe Garion ISAE-SUPAERO christophe.garion@isae-supaero.fr. Bases de données Yamine Aït-Ameur ENSEEIHT yamine@enseeiht.fr Christophe Garion ISAE-SUPAERO christophe.garion@isae-supaero.fr 2 novembre 2015 Table des matières 1. Introduction 3 2. Modèle de Chen 5 2.1.

Plus en détail

Quelques patterns pour la persistance des objets avec DAO DAO. Principe de base. Utilité des DTOs. Le modèle de conception DTO (Data Transfer Object)

Quelques patterns pour la persistance des objets avec DAO DAO. Principe de base. Utilité des DTOs. Le modèle de conception DTO (Data Transfer Object) Quelques patterns pour la persistance des objets avec DAO Ce cours présente des modèles de conception utilisés pour effectuer la persistance des objets Université de Nice Sophia-Antipolis Version 1.4 30/8/07

Plus en détail

2 ème PARTIE : LE LANGAGE SQL

2 ème PARTIE : LE LANGAGE SQL 2 ème PARTIE : LE LANGAGE SQL PLAN : I. Le langage de manipulation des données II. Le langage de définition des données III. Administration de la base de données IV. Divers (HORS PROGRAMME) Introduction:

Plus en détail

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2 éducalgo Manuel d utilisation 26 juin 2011 Table des matières 1 Tâche à effectuer : écrire un algorithme 2 2 Comment écrire un algorithme? 3 2.1 Avec quoi écrit-on? Avec les boutons d écriture........

Plus en détail

CONCEPTION des SYSTÈMES d INFORMATION UML

CONCEPTION des SYSTÈMES d INFORMATION UML CONCEPTION des SYSTÈMES d INFORMATION UML 4 : Analyse organique Epitech 3 Automne 2007 Bertrand LIAUDET SOMMAIRE ANALYSE ORGANIQUE 2 Diagrammes de séquence 3 Exemple de diagramme de séquence 8 Diagramme

Plus en détail

Exemple accessible via une interface Web. Bases de données et systèmes de gestion de bases de données. Généralités. Définitions

Exemple accessible via une interface Web. Bases de données et systèmes de gestion de bases de données. Généralités. Définitions Exemple accessible via une interface Web Une base de données consultable en ligne : Bases de données et systèmes de gestion de bases de données The Trans-atlantic slave trade database: http://www.slavevoyages.org/tast/index.faces

Plus en détail

Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes en banque (Philippe.Genoud@imag.fr)

Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes en banque (Philippe.Genoud@imag.fr) Grenoble 1 IMA Informatique & Mathématiques Appliquées UNIVERSITE JOSEPH FOURIER Sciences, Technologie, Médecine Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes

Plus en détail

BD50. TP5 : Développement PL/SQL Avec Oracle SQL Developer. Gestion Commerciale

BD50. TP5 : Développement PL/SQL Avec Oracle SQL Developer. Gestion Commerciale Département Génie Informatique BD50 TP5 : Développement PL/SQL Avec Oracle SQL Developer Gestion Commerciale Françoise HOUBERDON & Christian FISCHER Copyright Avril 2007 Présentation de la gestion commerciale

Plus en détail

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Chapitre 6 Exercices corrigés et conseils méthodologiques Mots-clés Activité continue/finie Transition automatique Contexte statique Événements «after»

Plus en détail

Bases de données. Yamine Aït-Ameur IRIT Enseeiht yamine@n7.fr. Christophe Garion ISAE garion@isae.fr

Bases de données. Yamine Aït-Ameur IRIT Enseeiht yamine@n7.fr. Christophe Garion ISAE garion@isae.fr Bases de données Yamine Aït-Ameur IRIT Enseeiht yamine@n7.fr Christophe Garion ISAE garion@isae.fr 4 février 2013 Table des matières 1 Introduction 1 2 Modèle de Chen 3 2.1 Généralités sur l information

Plus en détail

Objectifs du cours d aujourd hui. Informatique I : Cours d introduction à l informatique et à la programmation Structures de Données Abstraites & Tris

Objectifs du cours d aujourd hui. Informatique I : Cours d introduction à l informatique et à la programmation Structures de Données Abstraites & Tris Objectifs du cours d aujourd hui Informatique I : Cours d introduction à l informatique et à la programmation Structures de Données Abstraites & Tris Continuer l approfondissement de la programmation de

Plus en détail

SQL et Bases de données relationnelles. November 26, 2013

SQL et Bases de données relationnelles. November 26, 2013 November 26, 2013 SQL : En tant que langage d interrogation En tant que langage de mise à jour En tant que langage de définition de données Langages de requête Langages qui permettent d interroger la BD

Plus en détail

Introduction aux bases de données relationnelles

Introduction aux bases de données relationnelles Formation «Gestion des données scientifiques : stockage et consultation en utilisant des ases de données» 24 au 27 /06/08 Introduction aux ases de données relationnelles Christine Tranchant-Dureuil UMR

Plus en détail

SQL Description des données : création, insertion, mise à jour. Définition des données. BD4 A.D., S.B., F.C., N. G. de R.

SQL Description des données : création, insertion, mise à jour. Définition des données. BD4 A.D., S.B., F.C., N. G. de R. SQL Description des données : création, insertion, mise à jour BD4 AD, SB, FC, N G de R Licence MIASHS, Master ISIFAR, Paris-Diderot Mars 2015 BD4 (Licence MIASHS, Master ISIFAR, Paris-Diderot) SQL 1/21

Plus en détail

Du monde réel à SQL la modélisation des données

Du monde réel à SQL la modélisation des données ANF «Comment concevoir une base de données en archéométrie» Réseau CAI-RN & rbdd - 05/06/2014 au 06/06/2014 Du monde réel à SQL la modélisation des données Marie-Claude Quidoz (CEFE/CNRS) Ce document est

Plus en détail

Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1

Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1 Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1 Plan Généralités Langage de Définition des (LDD) Langage de Manipulation

Plus en détail

Points fixes de fonctions à domaine fini

Points fixes de fonctions à domaine fini ÉCOLE POLYTECHNIQUE ÉCOLE NORMALE SUPÉRIEURE DE CACHAN ÉCOLE SUPÉRIEURE DE PHYSIQUE ET DE CHIMIE INDUSTRIELLES CONCOURS D ADMISSION 2013 FILIÈRE MP HORS SPÉCIALITÉ INFO FILIÈRE PC COMPOSITION D INFORMATIQUE

Plus en détail

Fondements de l informatique: Examen Durée: 3h

Fondements de l informatique: Examen Durée: 3h École polytechnique X2013 INF412 Fondements de l informatique Fondements de l informatique: Examen Durée: 3h Sujet proposé par Olivier Bournez Version 3 (corrigé) L énoncé comporte 4 parties (sections),

Plus en détail

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface

Plus en détail

} 7 Variables (composantes)

} 7 Variables (composantes) Chapitre 4 Tableaux Jusqu ici, nous avons employé les variables pour stocker les valeurs individuelles de types primitifs : une variable de type int pour stocker un entier, une variable de type boolean

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Expressions rationnelles, automates, analyse lexicale

Expressions rationnelles, automates, analyse lexicale Chapitre 2 Expressions rationnelles, automates, analyse lexicale L analyse lexicale est la première phase d un compilateur ou d un interprète : elle consiste à identifier et à catégoriser les différents

Plus en détail

Résumé Introduction Programmation Java

Résumé Introduction Programmation Java Résumé Introduction Programmation Java Concepts Un programme : séquence, test conditionnel, boucles. Objets : Les objets Java modélisent les objets d un problème donné Classe : Les objets sont crées à

Plus en détail

Cours 7 : Langage de définition, manipulation et contrôle des données

Cours 7 : Langage de définition, manipulation et contrôle des données Cours 7 : Langage de définition, manipulation et contrôle des données Objets d une base de données Dans un schéma Tables, vues Index, clusters, séquences, synonymes Packages, procédures, fonctions, déclencheurs

Plus en détail

Mongi TRIKI Docteur en Informatique Université Paris Dauphine

Mongi TRIKI Docteur en Informatique Université Paris Dauphine Université Méditerranéenne Libre de Tunis Faculté Méditerranéenne Privée des Sciences Informatiques, Economiques et de Gestion de Tunis Département d Informatique LICENCE INFORMATIQUE Guide du Stagiaire

Plus en détail

Bases de données relationnelles

Bases de données relationnelles Bases de données relationnelles Système de Gestion de Bases de Données Une base de données est un ensemble de données mémorisé par un ordinateur, organisé selon un modèle et accessible à de nombreuses

Plus en détail

1/28. I Utiliser à bon escient les types de données proposés par SQL, ou. Introduction 3/28

1/28. I Utiliser à bon escient les types de données proposés par SQL, ou. Introduction 3/28 Introduction 1/28 2/28 Anne-Cécile Caron Licence MIAGE - BDD 2015-2016 Objectifs Après ce cours, les TD et TP correspondants, vous devez être capables de I Créer des tables à partir d un modèle I Utiliser

Plus en détail

IN 102 - Cours 1. 1 Informatique, calculateurs. 2 Un premier programme en C

IN 102 - Cours 1. 1 Informatique, calculateurs. 2 Un premier programme en C IN 102 - Cours 1 Qu on le veuille ou non, les systèmes informatisés sont désormais omniprésents. Même si ne vous destinez pas à l informatique, vous avez de très grandes chances d y être confrontés en

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation

Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation Bases de données Modèle relationnel BD relationnelle Observation de la réalité, Collecte d informations Réflexion et modélisation Définitions des tables d une BD relationnelle Obtenir une représentation

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

Base de données relationnelles Walter RUDAMETKIN

Base de données relationnelles Walter RUDAMETKIN Base de données relationnelles Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Le modèle relationnel Un schéma conceptuel est très pratique pour la phase d'analyse et conception Mais

Plus en détail

Bases de données et Systèmes transactionnels

Bases de données et Systèmes transactionnels Bases de données et Systèmes transactionnels Dominique Laurent dominique.laurent@u-cergy.fr Tao-Yan Jen jen@u-cergy.fr Plan du cours Introduction Modèle Entité/Association Langage SQL - ORACLE Architectures

Plus en détail

Patrons de conception prouvés

Patrons de conception prouvés Patrons de conception prouvés Thierry Lecomte 1 Dominique Méry 2 Dominique Cansell 2 (1) ClearSy, 320, avenue Archimède, Les Pléiades 3 Bât A 13857 Aix en Provence, France. (2) Loria, Université Henri

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

FlexIS: vers un système d intégration d information flexible

FlexIS: vers un système d intégration d information flexible FlexIS: vers un système d intégration d information flexible P. Colomb 1, et H. Jaudoin 2 1 LIMOS - CNRS UMR 6158, Université Blaise Pascal, France email: colomb@isima.fr LIMOS, 24 Avenue des Landais,

Plus en détail

PL/SQL. Pourquoi PL/SQL? Introduction. Principales caractéristiques de PL/SQL. Utilisation de PL/SQL

PL/SQL. Pourquoi PL/SQL? Introduction. Principales caractéristiques de PL/SQL. Utilisation de PL/SQL PL/SQL Avertissement : cette partie du cours n est qu un survol du langage PL/SQL, utile pour écrire des procédures stockées simples Elle laisse de côté de nombreuses fonctionnalités du langage Université

Plus en détail

I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel

I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel Introduction Notre contexte : pas possible d exprimer toutes les combinaisons de DT. Le test fonctionnel est basé sur la spécification/interface

Plus en détail

Chapitre 4 : Partie3 LANGAGE DE MANIPULATION RELATIONNEL : S Q L

Chapitre 4 : Partie3 LANGAGE DE MANIPULATION RELATIONNEL : S Q L Chapitre 4 : Partie3 LANGAGE DE MANIPULATION RELATIONNEL : S Q L SQL (Structured Query Language) est le langage de manipulation des données relationnelles le plus utilisé aujourd hui. Il est devenu un

Plus en détail

Bases de Données relationnelles et leurs systèmes de Gestion

Bases de Données relationnelles et leurs systèmes de Gestion III.1- Définition de schémas Bases de Données relationnelles et leurs systèmes de Gestion RAPPELS Contraintes d intégrité sous Oracle Notion de vue Typage des attributs Contrainte d intégrité Intra-relation

Plus en détail

Systèmes de gestion de bases de données

Systèmes de gestion de bases de données Systèmes de gestion de bases de données Introduction a la notion de transaction P. Rigaux Cnam, dépt. informatique May 20, 2015 PR (Cnam, dépt. info) Systèmes de gestion de bases de données May 20, 2015

Plus en détail

Le language SQL (2/2)

Le language SQL (2/2) Les commandes de base sous Unix SQL (Première partie) Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Création d'une base ([] facultatif) : createdb nombase [ -U comptepostgres ] Destruction

Plus en détail

Compte rendu d activité Fiche n 1

Compte rendu d activité Fiche n 1 Compte rendu d activité Fiche n 1 Alexandre K. (http://ploufix.free.fr) Nature de l activité Création d une base de connaissances avec PostgreSQL Contexte : Le responsable technique souhaite la mise en

Plus en détail

Chap. 4: Le modèle de données relationnel

Chap. 4: Le modèle de données relationnel Chap. 4: Le modèle de données relationnel Origine: E.F. Codd (1970). Modèle proche du modèle entité-association > présentation synthétique Intérêt (pour nous): - SGBD relationnels = tendance actuelle des

Plus en détail

LES CONCEPTS OBJETS. On regroupe les objets ayant les mêmes types de propriétés et de comportements en une classe.

LES CONCEPTS OBJETS. On regroupe les objets ayant les mêmes types de propriétés et de comportements en une classe. LES CONCEPTS OBJETS I Objet et Classe Un objet est une entité du monde réel qui a très souvent un identifiant des propriétés des comportements (actions qu il peut effectuer). La voiture de Clément a pour

Plus en détail

Indépendance données / applications

Indépendance données / applications Vues 1/27 Indépendance données / applications Les 3 niveaux d abstraction: Plusieurs vues, un seul schéma conceptuel (logique) et schéma physique. Les vues décrivent comment certains utilisateurs/groupes

Plus en détail

Instructions SQL. Première partie : Langage de description et de gestion des données

Instructions SQL. Première partie : Langage de description et de gestion des données Instructions SQL Première partie : Langage de description et de gestion des données Quelques instructions et leur syntaxe 1. Introduction Trois principales catégories d instructions. Instructions de création

Plus en détail

INF121: Algorithmique et Programmation Fonctionnelle

INF121: Algorithmique et Programmation Fonctionnelle INF121: Algorithmique et Programmation Fonctionnelle Cours 1: Identificateurs, types de base et fonctions Année 2013-2014 Identificateurs La notion d identificateur Un concept fondamental dans les langages

Plus en détail

UPMC Master informatique 2 STL NI503 Conception de langages Notes I

UPMC Master informatique 2 STL NI503 Conception de langages Notes I UPMC Master informatique 2 STL NI503 Conception de langages Notes I 2012 1 Évaluer Un langage Le langage Logo est composé commandes permettant de diriger le déplacement d un point sur un plan cartésien

Plus en détail

1 Position du problème

1 Position du problème Licence Science et Technologies - INF245 Examen session 1 - mai 2012 Durée : 2 heures Documents non autorisés Le barème est donné à titre indicatif 1 Position du problème Le Club Universitaire de Vélo

Plus en détail

Plan du cours. Introduction aux Bases de Données. Plan du cours. I. Introduction II. Le modèle UML III. Le modèle relationnel

Plan du cours. Introduction aux Bases de Données. Plan du cours. I. Introduction II. Le modèle UML III. Le modèle relationnel Plan du cours Introduction aux Bases de Données Maîtrise de Sciences Cognitives Année 2003-2004 Jérôme Darmont http://eric.univ-lyon2.fr/~jdarmont/ I. Introduction II. Le modèle UML III. Le modèle relationnel

Plus en détail

Encryptions, compression et partitionnement des données

Encryptions, compression et partitionnement des données Encryptions, compression et partitionnement des données Version 1.0 Grégory CASANOVA 2 Compression, encryption et partitionnement des données Sommaire 1 Introduction... 3 2 Encryption transparente des

Plus en détail

Compilation. Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP. Sandrine Blazy (d après le cours de François Pottier)

Compilation. Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP. Sandrine Blazy (d après le cours de François Pottier) Compilation Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP Sandrine Blazy (d après le cours de François Pottier) - 2 e année 10 novembre 2008 S.Blazy (ENSIIE) Compilation

Plus en détail

Plan. Bases de données. Cours 1 : Généralités & rappels. But du cours. Organisation du cours. Polytech Paris-Sud. Apprentis 4 ème année

Plan. Bases de données. Cours 1 : Généralités & rappels. But du cours. Organisation du cours. Polytech Paris-Sud. Apprentis 4 ème année Plan Bases de données Polytech Paris-Sud Apprentis 4 ème année Cours 1 : Généralités & rappels 1.1 Avant-propos 1.2 Algèbre relationnelle kn@lri.fr http://www.lri.fr/~kn 2/18 But du cours Organisation

Plus en détail

Introduction aux S.G.B.D.

Introduction aux S.G.B.D. NFE113 Administration et configuration des bases de données - 2010 Introduction aux S.G.B.D. Eric Boniface Sommaire L origine La gestion de fichiers Les S.G.B.D. : définition, principes et architecture

Plus en détail

JDBC et objet-relationnel

JDBC et objet-relationnel Types de données de SQL3 JDBC et objet-relationnel Université de Nice - Sophia Antipolis Version 1.6.4 5/11/11 Richard Grin JDBC supporte les types suivants de SQL3 qui sont des ouvertures vers le relationnelobjet

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e

Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e P r o b l é m a t i q u e OCL : O b j e c t C o n s t r a i n t L a n g u a g e Le langage de contraintes d UML Les différents diagrammes d UML permettent d exprimer certaines contraintes graphiquement

Plus en détail

Vérification formelle d un modèle mémoire pour le langage C

Vérification formelle d un modèle mémoire pour le langage C Vérification formelle d un modèle mémoire pour le langage C Projet ANR ARA SSIA CompCert (http://compcert.inria.fr) Sandrine Blazy, Xavier Leroy CEDRIC-ENSIIE et INRIA Rocquencourt CEA-LIST, 18 mars 2008

Plus en détail

Modèle Entité/Association. Marc Plantevit. marc.plantevit@liris.cnrs.fr

Modèle Entité/Association. Marc Plantevit. marc.plantevit@liris.cnrs.fr Modèle Entité/Association Marc Plantevit marc.plantevit@liris.cnrs.fr Objectifs Savoir lire un schéma E/R. Savoir traduire un schéma E/R en Modèle Relationnel.... 2 Le modèle Entité-Association (E/A) E/R

Plus en détail

1. Base de données SQLite

1. Base de données SQLite Dans ce TP, nous allons voir comment créer et utiliser une base de données SQL locale pour stocker les informations. La semaine prochaine, ça sera avec un WebService. On repart de l application AvosAvis

Plus en détail