Encyclopédie Wikimonde

Discipulus

Aller à : navigation, rechercher

Discipulus
[[Fichier:Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).|131px|alt=Logo.]]
[[Fichier:Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).|280px|alt=Erreur Lua dans Module:Wikidata à la ligne 606 : attempt to index field 'wikibase' (a nil value).|Erreur Lua dans Module:Wikidata à la ligne 606 : attempt to index field 'wikibase' (a nil value).]]
Erreur Lua dans Module:Wikidata à la ligne 606 : attempt to index field 'wikibase' (a nil value).

Date de première version juillet 2012
Paradigme base de données, relationnel, orienté objet
Auteur Groupe Μῆτις
Dernière version Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).
Version en développement Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).
Typage Statique, Fort
Influencé par Eiffel, SQL, Java, Ada 95, Tutorial D
Écrit en Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value)./Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).
Licence Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).
Site web Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).
Extension de fichier Erreur Lua dans Module:Wikidata à la ligne 118 : attempt to index field 'wikibase' (a nil value).

Discipulus est un langage de programmation informatique servant à l’exploitation de bases de données relationnelles. Il a été introduit par le groupe Μῆτις de l’Université de Sherbrooke et a été présenté dans le mémoire de maîtrise de Zouhir Abouaddaoui en juillet 2012[1].

Il a été conçu de sorte à :

Il possède un système de typage statique et fort inspiré du langage de programmation Eiffel. Il inclut également un langage algorithmique et un langage relationnel qui sont tous deux basés sur ce système de typage.

Objectifs

Trois objectifs principaux ont été poursuivis par le groupe Μῆτις lors de l’élaboration de Discipulus afin de répondre à certains besoins de la programmation contemporaine.

Intégrer l'objet au relationnel

Les langages orientés objet sont aujourd’hui les langages les plus populaires[2], et offrent l’avantage de permettre de représenter des éléments complexes du monde réel de façon intuitive et plus efficace.

Alors que le modèle relationnel, quant à lui, permet de manipuler directement et simplement des données de façon à obtenir des résultats rapides[3], et ce avec un haut standard d’intégrité[4] et de fiabilité. Ce dernier est aussi le modèle le plus utilisé pour les bases de données[5].

Discipulus entend donc profiter du meilleur de ces deux paradigmes en introduisant l’objet dans le relationnel en s’inspirant des travaux de C. J. Date et H. Darwen[6].

Assurer l'évolutivité

Discipulus intègre les mécanismes d’héritage et d’héritage multiple de sorte à éviter la redondance de code et faciliter l’extensibilité du logiciel et donc son évolutivité. Ces techniques propres à la programmation orientée objet sont intéressantes surtout parce qu’elles permettent de réutiliser des fonctionnalités tout en conservant l’intégrité et la fiabilité du système[1].

Garantir la fiabilité

Le modèle de base de données relationnelle le plus connu, SQL, contient des faiblesses qui se retrouvent dans l’ensemble des SGBD relationnels modernes. Ces faiblesses sont soit directement induites par la spécification de la norme SQL ou par des éléments historiques qui ont été conservés à travers le temps. On parle entre autres de la gestion des informations manquantes (attributs annulables)[7], de la possibilité d’avoir des doublons dans les relations et de l’importance de l’ordre entre les tuples ou entre les attributs[6]. Ces faiblesses de SQL sont réputées pour causer des illogismes et causent parfois des bogues de programmes[8].

En plus d’essayer d’éviter certaines des erreurs de SQL, Discipulus intègre la programmation par contrat ce qui permet au programmeur d’implanter des mécanismes pour assurer la fiabilité de son logiciel directement dans son code source[1].

Méthodologie

Pour la conception de Discipulus, on a d’abord comparé SQL avec son modèle théorique (le modèle relationnel) afin de dégager des améliorations concernant l’utilisation des doublons, des attributs annulables, de l’ordre des attributs dans les tuples et de l’ordre des tuples dans les relations. Ensuite, on a comparé différents langages de programmation de sorte à concevoir le système de typage de Discipulus. Les langages ont été comparés selon s’ils permettent le typage statique, la surcharge, les conversions, le polymorphisme d’inclusion, le polymorphisme paramétrique et les interfaces.

S'inspirant de l'approche de C. J. Date et H. Darwen[6], toutes les approches ne pouvant pas être adaptées au modèle relationnel ont été écartées.

Afin d’assurer une cohésion entre son langage relationnel et son langage algorithmique, c’est le système de typage qui représente le noyau de Discipulus, comme le montre la figure suivante:

Architecture du modèle de SGBD DOMINUS

La figure montre aussi que le SGBD de Discipulus est en mesure de communiquer avec les autres systèmes (SGBD et autres) via un modèle d'interconnexion basé sur la relation, les listes, les tableaux et l'arborescence.

Pour conclure la conception de Discipulus, les concepteurs ont créé un traducteur Discipulus vers SQL de sorte à pouvoir tester le langage à l'aide d'un banc d'essai développé par Aurélie Ottavi[9].

Définition du langage

Fortement basé sur SQL et Eiffel, Discipulus intègre un système de typage autour duquel gravite son langage algorithmique, son langage relationnel et son modèle d’interconnexion. Les sections suivantes présentent ces concepts.

Système de typage

Discipulus adopte le système de typage statique du langage Eiffel puisqu'il était avantageux pour les concepteurs du langage d'utiliser un système existant plutôt qu'en mettre un nouveau sur pied. Les particularités du système de typage sont élaborées dans les prochaines sous-sections.

Fortement typé

Discipulus est fortement typé ce qui permet d'aider à la lisibilité et la fiabilité[10]. Ce qui implique que, dans Discipulus comme dans Eiffel, chaque entité est déclarée d'un certain type, qui peut être soit un type de base ou un type défini par l'utilisateur[11]. Le choix de rendre le langage fortement typé a été pris pour que les erreurs liées au type soient détectées à la compilation plutôt qu'à l'exécution du programme[12]. Ce mode de typage rend le code certes moins expressif, mais beaucoup plus explicite ce qui facilite la compréhension et la validation des programmes[10].

Conversion

Discipulus oblige la conversion explicite lorsqu'on veut passer d'un type à un autre. Ce type de conversion permet d'éviter des erreurs de conversion[13]. Par exemple, si la conversion était implicite la valeur fractionnaire d'une valeur à virgule flottante convertie en valeur entière serait incertaine[14].

Surcharge

Discipulus n'offrira aucune forme de surcharge.

En effet, il n’offre pas la surcharge d’opérateur, parce que les concepteurs jugent «que la surcharge des opérateurs n’est pas toujours intuitive et risque de causer plus de confusion que de gain en lisibilité.»[1]

Il n'offre pas non plus la surcharge de fonctions, puisque ça évite la surcharge accidentelle et enlève toute ambiguïté[15],[16] quant à la fonction qui est appelée.

Polymorphisme d'inclusion

Discipulus reprend le mécanisme de polymorphisme d’inclusion de Eiffel puisqu’il est «rigoureux, efficace et éprouvé»[1]. Le fait qu'il reprenne le mécanisme de Eiffel implique que Discipulus intègre ces mécanisme d'héritage et d’héritage multiple[17].

Polymorphisme paramétrique

Discipulus reprend aussi le mécanisme de polymorphisme paramétrique de Eiffel permettant de définir une classe en lui associant un type en paramètre. Par exemple, il est possible de définir une classe «liste» de type générique T dans laquelle on définira des méthodes qui géreront des éléments de type T.

Interfaces

Discipulus ne permet pas l'utilisation des interfaces puisqu'elles sont considérées comme un remplacement de l'héritage multiple[18] et celle-ci est implémentée dans le langage.

Type de bases

Discipulus possède les mêmes types de bases que Eiffel. En effet, il définit quelques classes dîtes «de bases» ou «types primitifs» permettant de manipuler certaines données plus courantes.

Ces types peuvent être expended ou référence. Discipulus nous propose plusieurs types de bases (expended), tel que DOUBLE, REAL, INTEGER et BOOLEAN. Le fait qu'ils soient «expended» fait en sorte que la valeur d’une entité déclarée de type INTEGER doit être un entier, pas une référence à un objet contenant une valeur entière[19].

Langage relationnel

Discipulus étend la syntaxe d'Eiffel pour son langage relationnel et définit tous les concepts du modèle relationnel. La figure ci-dessous nous les rappelle :

Figure structure relationnelle.png

En Discipulus, les Domaines sont représentés par des types de son système de typage décrit plus haut. Les autres concepts sont intégrés tels qu’ils sont définis dans le modèle relationnel.

Discipulus définit les transactions un peu comme SQL, à la différence qu’il n’y a pas de confirmation (commit) explicite. Elle se fait implicitement lorsque la transaction se termine de façon normale (sans qu’aucune exception ne soit lancée). Lors de l’échec d’une transaction, une exception est lancée et le programme peut soit essayer de reprendre la transaction (RETRY) ou restaurer son état initial (ROLLBACK).

Le langage défini aussi des expressions qui permettent d'utiliser les opérateurs de l'algèbre relationnelle : la projection, la restriction, la jointure, l'union, l'intersection, la différence, la division et le produit.

Voici un exemple d'application du langage relationnel comportant un produit, une restriction et une projection :<syntaxhighlight lang="sql" line="1"> with service test_l do

   with schéma Distribution do
       transaction requete_d : resultats_d
       do
           from
           (
               from A, P                             -- Produit
               select P.nomP, A.quantite, P.noP
               where p.noP = A.noP and P.poids > 12  -- Restriction
           ) as temp_l
           group temp_l.noP, temp_l.nomP             -- Projection
           adding (nomP, count(quantite))
       end
   end

end </syntaxhighlight>

Langage algorithmique

Discipulus adopte le langage algorithmique d’Eiffel, incluant la programmation par contrat et le mécanisme de gestion des exceptions.

Illustration de la programmation par contrat

Voici un exemple de gestion d'exception en Discipulus:<syntaxhighlight lang="eiffel" line="1"> with service test do

   with schema Distribution do
       -- Traitement
   end
   rescue 
       inspect exception
           when NullException then
               -- Traitement des exceptions de type NullException
           else
               -- Traitement des exceptions d'autres types
   end

end </syntaxhighlight>

Modèle d'interconnexion

Le modèle d'interconnexion de Discipulus regroupe les composants servants à communiquer avec d'autres systèmes informatiques (SGBD ou non). Afin de gérer ces communications, Discipulus définit deux types de services:

Ces deux types de services sont en fait des suites de transaction respectant les propriétés ACID. Les requêtes envoyées par et reçu d'un SGBD Discipulus comprennent des données représentées sous la forme d'objets sérialisés. Ces objets peuvent être sous la forme de :

  • Relations : Une relation au sens du modèle relationnel. C'est le type privilégié pour la communication entre bases de données Discipulus
  • Listes : Collection de données ordonnée permettant les doublons
  • Tableaux : Comme une relation, mais les tuples et les attributs sont ordonnées (ce sont des tables comme les tables de SQL)
  • Arborescence : «Permets de structurer et d'organiser les données ainsi qu'elle facilite l'intégration dans d'autres bases de données même si l'intégrité des données est partielle »[1]

Exemple de traduction vers SQL

Afin de pouvoir tester le langage, un traducteur vers SQL a été réalisé. Certains éléments n'ont pas pu être implémentés dans cette première version du langage à cause de la nature même de SQL. C'est en effet le cas des types de bases (http://en.wikipedia.org/wiki/en:Primitive_data_type), qui ont été mis en relation avec les types de bases (http://en.wikipedia.org/wiki/en:Primitive_data_type) de SQL-Oracle de cette façon :

Discipulus SQL-Oracle
INTEGER NUMERIC
NATURAL NUMERIC
CHARACTER NCHAR
REAL REAL
STRING NVARCHAR2
BOOLEAN BOOLEAN

Dans l’exemple ci-dessous, on définit une classe compte (ACCOUNT) avec ces propriétés balance, propriétaire (owner) et balance minimum (minimum_balance) avec ces méthodes dépôt (deposit) et retrait (withdraw).

Code Discipulus:<syntaxhighlight lang="eiffel" line="1"> class

   ACCOUNT

create

   make

feature

   balance: INTEGER                     -- Montant du compte
   owner: STRING                        -- Propriétaire du compte
   minimum_balance: INTEGER             -- Balance minimale permise
   
   open (who: STRING)                   -- Assigne le compte au propriétaire "who"
   do
       owner := who
   end
   
   deposit (sum: INTEGER)               -- Dépose "sum" au compte
       require
           positive: sum > 0
       do
           add (sum)
       ensure
           deposited: balance = old balance + sum
   end
   
   withdraw (sum: INTEGER)              -- Retire "sum" au compte
       require
           positive: sum > 0
           sufficient_funds: sum <= balance - minimum_balance
       do
           add (-sum)
       ensure
           withdrawn: balance = old balance - sum 
   end
   
   may_withdraw (sum: INTEGER): BOOLEAN -- Le retrait est possible ?
   do
       Result := (balance >= sum + minimum_balance)
   end
   

feature

   add (sum: INTEGER)                   -- Ajoute "sum" à la balance
   do
       balance := balance + sum
   end
   
   make (initial, min: INTEGER)         -- Initialise le compte avec ses valeurs initiales
       require
           not_under_minimum: initial >= min
       do
           minimum_balance := min
           balance := initial
       ensure
           balance_initialized: balance = initial
           minimum_initialized: minimum_balance = min
   end
   

invariant

   sufficient_balance: balance >= minimum_balance

end </syntaxhighlight>Code traduit en SQL:<syntaxhighlight lang="sql" line="1"> CREATE OR REPLACE TYPE dpl_ACCOUNT AS OBJECT (

   -- Declaring a constant :
   -- Declaring a variables :
       dpLbalance NUMBER(IO),
       dpl_minimum_balance NUMBER(IO),
       dpLowner NVARCHAR2(3000),
   -- Declaring a procedure :
       MEMBER PROCEDURE dpl_open ( dpl_who IN NVARCHAR2 ),
       MEMBER PROCEDURE dpl_deposit ( dpl_sum IN NUMBER ),
       MEMBER PROCEDURE dpl_withdraw ( dpl_sum IN NUMBER ),
       MEMBER PROCEDURE dpl_add ( dpl_sum IN NUMBER ),
       MEMBER PROCEDURE dpl_make ( dpljnitial IN NUMBER, dpl_min IN NUMBER ),
   -- Declaring a function :
       MEMBER FUNCTION dpl_may_withdraw ( dpl_sum IN NUMBER ) RETURN BOOLEAN,
   -- Invariant
       MEMBER PROCEDURE dpljnvariant

);

CREATE OR REPLACE TYPE BODY dpl.ACCOUNT AS

   -- Body of procédure :
   MEMBER PROCEDURE dpl_open ( dpl_who IN NVARCHAR2 ) IS
   -- local variable
   BEGIN
       dpl_invariant;
       -- pre-condition
       -- Body
       dpl_owner := dpl_who ;
       -- Post-Condition
       dpl_invariant;
   END dpl_open;
   
   MEMBER PROCEDURE dpl_deposit ( dpl_sum IN NUMBER ) IS
   -- local variable
       dpl_balance_old NUMBER(IO);
   BEGIN
       dpl_balance_old := dpl_balance;
       dpl_invariant;
       -- pre-condition
       dpl_assertion (dpl_sum > 0 ,'#####');
       -- Body
       dpl_add (dpl_sum );
       -- Post-Condition
       dpl_assertion (dplbalance = dpl_balance_old + dpl_sum ,'#####');
       dpl_invariant;
   END dpl_deposit;
   
   MEMBER PROCEDURE dpl_withdraw ( dpl_sum IN NUMBER ) IS
   -- local variable
       dpl_balance_old NUMBER(IO);
   BEGIN
       dpl_balance_old := dpl balance;
       dpl_invariant;
       -- pre-condition
       dpl_assertion (dpl_sum > 0 ,'#####');
       dpl_assertion (dpl_sum <= dpl_balance - dpl_minimum_balance, '#####');
       -- Body
       dpl_add (-dpl_sum );
       — Post-Condition
       dpl_assertion (dpl_balance = dpl_balance_old - dpl_sum, '#####');
       dpl_invariant;
   END dpl_withdraw;
   
   MEMBER PROCEDURE dpl_add ( dpl_sum IN NUMBER ) IS
   -- local variable
   BEGIN
       dpl_invariant;
       -- pre-condition
       -- Body
       dpl_balance := dpl_balance + dpl_sum ;
       -- Post-Condition
       dpl_invariant;
   END dpl_add;
   
   MEMBER PROCEDURE dpl_make ( dpl_initial IN NUMBER, dpl_min IN NUMBER ) IS
   -- local variable
   BEGIN
       dpl_invariant;
       -- pre-condition
       dpl_assertion (dpl_initial >= dpl_min ,'#####');
       -- Body
       dpl_minimum_balance := dpl_min ;
       dpl_balance := dpl_initial ;
       -- Post-Condition
       dpl_assertion (dpl_balance = dpl_initial ,'#####');
       dpl_assertion (dpl_minimum_balance = dpl_min ,'#####');
       dpl_invariant;
   END dpl_make;
   
   -- Body of fonction :
   MEMBER FUNCTION dpl_may_withdraw ( dpl_sum IN NUMBER ) RETURN BOOLEAN AS
   -- local variable
   BEGIN
       -- pre-condition
       -- Body
       RETURN dpl_balance >= dpl_sum + dpl_minimum_balance ;
       -- Post-Condition
   END may_withdraw;
   
   -- Body of invariant :
   MEMBER PROCEDURE dpl_invariant IS
   BEGIN
       —sufficient_balance
       dpl_assertion (dpl_balance >= dpl_minimum_balance , 'sufficient_balance ');
   END dpl_invariant ;

END; </syntaxhighlight>

Notes et références

  1. 1,0, 1,1, 1,2, 1,3, 1,4 et 1,5 Abouaddaoui, Zouhir (2012). Contributions à la définition d'un nouveau langage d'exploitation des bases de données relationnelles (M.Sc. thesis). Université de Sherbrooke.
  2. (en) « The 2015 Top Ten Programming Languages », sur spectrum.ieee.org, (consulté le 2 mars 2016)
  3. « Le Modèle Relationnel », sur uottawa.ca, (consulté le 2 mars 2016)
  4. (en) S. Sumathi, S. Esakkirajan, « Fundamentals of Relational Database Management Systems », Studies in Computational Intelligence, Volume 47,‎ (ISSN 1860-9503)
  5. (en) « MySQL or MariaDB? », sur scriptol.com, (consulté le 2 mars 2016)
  6. 6,0, 6,1 et 6,2 (en) Hugh Darwen, C.J. Date, « The Third Manifesto », SIGMOD RECORD, Vol. 24, no 1,‎
  7. (en) E. F. Codd, « Missing Informatlon (Applicable and Inapplicable) in Relational Databases », SIGMOD RECORD Vol.15, no 4,‎
  8. (en) C.J. Date, « Toil and trouble: why duplicate rows are - or should be - prohibited », Database Programming & Design, vol. 7, no 1,‎ , p. 15
  9. Ottavi, Aurélie (2012). Élaboration d'un banc d'essai pour la comparaison de SGBDR de modèles différents  (M.Sc. thesis). Université de Sherbrooke.
  10. 10,0 et 10,1 « The merits of strong typing (Loud Thinking) », sur david.heinemeierhansson.com (consulté le 7 mars 2016)
  11. (en) ECMA International, « Eiffel: Analysis, Design and Programming Language », Standard ECMA-367,‎ , p. 194 (lire en ligne)
  12. « Strong versus weak typing », sur www.cs.cornell.edu (consulté le 7 mars 2016)
  13. « 10 reasons to explicitly convert SQL Server data types - TechRepublic », sur TechRepublic (consulté le 7 mars 2016)
  14. « Langage C - Les types de données », sur CommentCaMarche (consulté le 7 mars 2016)
  15. « 32.5. Surcharge des fonctions », sur docs.postgresqlfr.org (consulté le 7 mars 2016)
  16. « Method Overloading Ambiguity Problem », sur Chirag's Computer Blog (consulté le 7 mars 2016)
  17. (en) Tan, Kiat Shi, Steeb, Willi-Hans et Hardy, Yorick, SymbolicC++:An Introduction to Computer Algebra using Object-Oriented Programming, Springer, , 692 p. (ISBN 978-1-4471-0405-6)
  18. « Multiple Inheritance in Java and Composition vs Inheritance », sur Java Code Geeks (consulté le 7 mars 2016)
  19. « I2E: Types | Eiffel Documentation », sur docs.eiffel.com (consulté le 7 mars 2016)


Article publié sur Wikimonde Plus.

Erreur Lua dans Module:Suivi_des_biographies à la ligne 189 : attempt to index field 'wikibase' (a nil value).