Bienvenue sur EveryBodyWiki ! Créez un compte ou connectez vous pour participer, améliorer ou créer un article, une biographie (la vôtre ?), une page entreprise...


Discipulus

De EverybodyWiki Bios & Wiki
Sauter à la navigation Sauter à la recherche


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 à :

  • Permettre la représentation d’éléments complexes de la vie réelle par l’intégration de la programmation orientée objet au modèle relationnel
  • Assurer l’évolutivité avec les mécanismes d’héritage et d’héritage multiple
  • Garantir la fiabilité par l’incorporation des principes de programmation par contrat et en corrigeant certaines lacunes qu’on retrouve dans les systèmes de gestion de base de données (abr. SGBD) relationnels existants.

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[modifier]

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[modifier]

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é[modifier]

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é[modifier]

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[modifier]

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[modifier]

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[modifier]

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é[modifier]

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[modifier]

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[modifier]

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[modifier]

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[modifier]

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[modifier]

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[modifier]

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[modifier]

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 :

 1 with service test_l do
 2     with schéma Distribution do
 3         transaction requete_d : resultats_d
 4         do
 5             from
 6             (
 7                 from A, P                             -- Produit
 8                 select P.nomP, A.quantite, P.noP
 9                 where p.noP = A.noP and P.poids > 12  -- Restriction
10             ) as temp_l
11             group temp_l.noP, temp_l.nomP             -- Projection
12             adding (nomP, count(quantite))
13         end
14     end
15 end

Langage algorithmique[modifier]

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:

 1 with service test do
 2     with schema Distribution do
 3         -- Traitement
 4     end
 5     rescue 
 6         inspect exception
 7             when NullException then
 8                 -- Traitement des exceptions de type NullException
 9             else
10                 -- Traitement des exceptions d'autres types
11     end
12 end

Modèle d'interconnexion[modifier]

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:

  • Les commandes : modifient la base de données
  • Les requêtes: retournent un objet construit avec les données de la base de données

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[modifier]

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, qui ont été mis en relation avec les types de bases 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:

 1 class
 2     ACCOUNT
 3 create
 4     make
 5 feature
 6     balance: INTEGER                     -- Montant du compte
 7     owner: STRING                        -- Propriétaire du compte
 8     minimum_balance: INTEGER             -- Balance minimale permise
 9     
10     open (who: STRING)                   -- Assigne le compte au propriétaire "who"
11     do
12         owner := who
13     end
14     
15     deposit (sum: INTEGER)               -- Dépose "sum" au compte
16         require
17             positive: sum > 0
18         do
19             add (sum)
20         ensure
21             deposited: balance = old balance + sum
22     end
23     
24     withdraw (sum: INTEGER)              -- Retire "sum" au compte
25         require
26             positive: sum > 0
27             sufficient_funds: sum <= balance - minimum_balance
28         do
29             add (-sum)
30         ensure
31             withdrawn: balance = old balance - sum 
32     end
33     
34     may_withdraw (sum: INTEGER): BOOLEAN -- Le retrait est possible ?
35     do
36         Result := (balance >= sum + minimum_balance)
37     end
38     
39 feature
40     add (sum: INTEGER)                   -- Ajoute "sum" à la balance
41     do
42         balance := balance + sum
43     end
44     
45     make (initial, min: INTEGER)         -- Initialise le compte avec ses valeurs initiales
46         require
47             not_under_minimum: initial >= min
48         do
49             minimum_balance := min
50             balance := initial
51         ensure
52             balance_initialized: balance = initial
53             minimum_initialized: minimum_balance = min
54     end
55     
56 invariant
57     sufficient_balance: balance >= minimum_balance
58 end

Code traduit en SQL:

  1 CREATE OR REPLACE TYPE dpl_ACCOUNT AS OBJECT (
  2     -- Declaring a constant :
  3     -- Declaring a variables :
  4         dpLbalance NUMBER(IO),
  5         dpl_minimum_balance NUMBER(IO),
  6         dpLowner NVARCHAR2(3000),
  7     -- Declaring a procedure :
  8         MEMBER PROCEDURE dpl_open ( dpl_who IN NVARCHAR2 ),
  9         MEMBER PROCEDURE dpl_deposit ( dpl_sum IN NUMBER ),
 10         MEMBER PROCEDURE dpl_withdraw ( dpl_sum IN NUMBER ),
 11         MEMBER PROCEDURE dpl_add ( dpl_sum IN NUMBER ),
 12         MEMBER PROCEDURE dpl_make ( dpljnitial IN NUMBER, dpl_min IN NUMBER ),
 13     -- Declaring a function :
 14         MEMBER FUNCTION dpl_may_withdraw ( dpl_sum IN NUMBER ) RETURN BOOLEAN,
 15     -- Invariant
 16         MEMBER PROCEDURE dpljnvariant
 17 );
 18 
 19 CREATE OR REPLACE TYPE BODY dpl.ACCOUNT AS
 20     -- Body of procédure :
 21     MEMBER PROCEDURE dpl_open ( dpl_who IN NVARCHAR2 ) IS
 22     -- local variable
 23     BEGIN
 24         dpl_invariant;
 25         -- pre-condition
 26         -- Body
 27         dpl_owner := dpl_who ;
 28         -- Post-Condition
 29         dpl_invariant;
 30     END dpl_open;
 31     
 32     MEMBER PROCEDURE dpl_deposit ( dpl_sum IN NUMBER ) IS
 33     -- local variable
 34         dpl_balance_old NUMBER(IO);
 35     BEGIN
 36         dpl_balance_old := dpl_balance;
 37         dpl_invariant;
 38         -- pre-condition
 39         dpl_assertion (dpl_sum > 0 ,'#####');
 40         -- Body
 41         dpl_add (dpl_sum );
 42         -- Post-Condition
 43         dpl_assertion (dplbalance = dpl_balance_old + dpl_sum ,'#####');
 44         dpl_invariant;
 45     END dpl_deposit;
 46     
 47     MEMBER PROCEDURE dpl_withdraw ( dpl_sum IN NUMBER ) IS
 48     -- local variable
 49         dpl_balance_old NUMBER(IO);
 50     BEGIN
 51         dpl_balance_old := dpl balance;
 52         dpl_invariant;
 53         -- pre-condition
 54         dpl_assertion (dpl_sum > 0 ,'#####');
 55         dpl_assertion (dpl_sum <= dpl_balance - dpl_minimum_balance, '#####');
 56         -- Body
 57         dpl_add (-dpl_sum );
 58          Post-Condition
 59         dpl_assertion (dpl_balance = dpl_balance_old - dpl_sum, '#####');
 60         dpl_invariant;
 61     END dpl_withdraw;
 62     
 63     MEMBER PROCEDURE dpl_add ( dpl_sum IN NUMBER ) IS
 64     -- local variable
 65     BEGIN
 66         dpl_invariant;
 67         -- pre-condition
 68         -- Body
 69         dpl_balance := dpl_balance + dpl_sum ;
 70         -- Post-Condition
 71         dpl_invariant;
 72     END dpl_add;
 73     
 74     MEMBER PROCEDURE dpl_make ( dpl_initial IN NUMBER, dpl_min IN NUMBER ) IS
 75     -- local variable
 76     BEGIN
 77         dpl_invariant;
 78         -- pre-condition
 79         dpl_assertion (dpl_initial >= dpl_min ,'#####');
 80         -- Body
 81         dpl_minimum_balance := dpl_min ;
 82         dpl_balance := dpl_initial ;
 83         -- Post-Condition
 84         dpl_assertion (dpl_balance = dpl_initial ,'#####');
 85         dpl_assertion (dpl_minimum_balance = dpl_min ,'#####');
 86         dpl_invariant;
 87     END dpl_make;
 88     
 89     -- Body of fonction :
 90     MEMBER FUNCTION dpl_may_withdraw ( dpl_sum IN NUMBER ) RETURN BOOLEAN AS
 91     -- local variable
 92     BEGIN
 93         -- pre-condition
 94         -- Body
 95         RETURN dpl_balance >= dpl_sum + dpl_minimum_balance ;
 96         -- Post-Condition
 97     END may_withdraw;
 98     
 99     -- Body of invariant :
100     MEMBER PROCEDURE dpl_invariant IS
101     BEGIN
102         sufficient_balance
103         dpl_assertion (dpl_balance >= dpl_minimum_balance , 'sufficient_balance ');
104     END dpl_invariant ;
105 END;

Notes et références[modifier]

  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)

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


Autres articles du thème Informatique informatique : Outscale, Dispositif sociotechnique pour l'information et la communication, Spie Communications, Guillaume Langlois, Meaning of a Tag, Internationalisation (informatique), Cyberoam


Cet Article wiki "Discipulus" est issu de Wikipedia. La liste de ses auteurs peut être visible dans ses historiques et/ou la page Edithistory:Discipulus.



Compte Twitter EverybodyWiki Follow us on https://twitter.com/EverybodyWiki !