Discipulus
| 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). | |
modifier  |
||
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:
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 :
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 :
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
Langage algorithmique[modifier]
Discipulus adopte le langage algorithmique d’Eiffel, incluant la programmation par contrat et le mécanisme de gestion des exceptions.
Voici un exemple de gestion d'exception en Discipulus:
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
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:
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
Code traduit en SQL:
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;
Notes et références[modifier]
- ↑ 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.
- ↑ (en) « The 2015 Top Ten Programming Languages », sur spectrum.ieee.org, (consulté le 2 mars 2016)
- ↑ « Le Modèle Relationnel », sur uottawa.ca, (consulté le 2 mars 2016)
- ↑ (en) S. Sumathi, S. Esakkirajan, « Fundamentals of Relational Database Management Systems », Studies in Computational Intelligence, Volume 47, (ISSN 1860-9503)
- ↑ (en) « MySQL or MariaDB? », sur scriptol.com, (consulté le 2 mars 2016)
- ↑ 6,0 6,1 et 6,2 (en) Hugh Darwen, C.J. Date, « The Third Manifesto », SIGMOD RECORD, Vol. 24, no 1,
- ↑ (en) E. F. Codd, « Missing Informatlon (Applicable and Inapplicable) in Relational Databases », SIGMOD RECORD Vol.15, no 4,
- ↑ (en) C.J. Date, « Toil and trouble: why duplicate rows are - or should be - prohibited », Database Programming & Design, vol. 7, no 1, , p. 15
- ↑ 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,0 et 10,1 « The merits of strong typing (Loud Thinking) », sur david.heinemeierhansson.com (consulté le 7 mars 2016)
- ↑ (en) ECMA International, « Eiffel: Analysis, Design and Programming Language », Standard ECMA-367, , p. 194 (lire en ligne)
- ↑ « Strong versus weak typing », sur www.cs.cornell.edu (consulté le 7 mars 2016)
- ↑ « 10 reasons to explicitly convert SQL Server data types - TechRepublic », sur TechRepublic (consulté le 7 mars 2016)
- ↑ « Langage C - Les types de données », sur CommentCaMarche (consulté le 7 mars 2016)
- ↑ « 32.5. Surcharge des fonctions », sur docs.postgresqlfr.org (consulté le 7 mars 2016)
- ↑ « Method Overloading Ambiguity Problem », sur Chirag's Computer Blog (consulté le 7 mars 2016)
- ↑ (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)
- ↑ « Multiple Inheritance in Java and Composition vs Inheritance », sur Java Code Geeks (consulté le 7 mars 2016)
- ↑ « 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).
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.
