CONCEPT


FOCUS SUR LE LOGICIEL

Présentation
Points Clés
Concepts

Conception Intuitive


Homme et Intéractions


Développement Informatique


Gestion des Types


Propriétés des Objets


Création d’Objets


Propriétés


Evènementiel


Conclusion

 

Conception Intuitive des Applications


Un logiciel doit être déterministe. Nous nous attendons à ce qu'il produise les mêmes résultats s'il est utilisé dans les mêmes conditions, et qu’il soit prévisible. Pour créer de telles applications, nous utilisons des outils déterministes tels que le langage de programmation. A cause de ces outils déterministes et parce qu’en tant qu’humain, nos langages et nos comportements ne sont pas déterministes, la programmation est une tâche difficile.

Kallisté crée des applications logicielles déterministes mais n'est pas déterministe par lui-même. Vous pouvez donc l'utiliser intuitivement, comme vous le feriez avec les objets qui vous entourent.

C'est ce qu'on appelle: LA PROGRAMMATION INTUITIVE.

Le Concept Kallisté s’appuie sur notre fonctionnement naturel.

Pour présenter le Concept Kallisté de manière précise, il est important de rappeler des notions qui nous sont tellement naturelles et auxquelles nous n’accordons que peu d’intérêt au quotidien.

 

L’Homme et ses Interactions


Si nous omettons les caractéristiques humaines abstraites (humeur, sentiments, beauté, etc...,), nous mettons toujours en œuvre les mêmes interactions avec notre environnement.

Prédicat 1 : L’homme interagit avec son environnement par un jeu limité d’interactions intuitives.

Ces interactions dépendent essentiellement du sujet avec lequel nous interagissons. S’il s’agit d’un congénère, nous communiquons au moyen d’un langage (oral ou écrit). Hors, aussi étonnant que cela puisse paraître, un langage humain, de par sa sémantique, n’est jamais déterministe. En voici un exemple simple :
  • « Pierre monte un escalier »
  • « Jean monte un modèle réduit »
Nous comprenons aisément ces deux phrases, pourtant elles utilisent le même verbe « monter ». Hors passer du rez-de-chaussée au premier étage n’a vraiment rien à voir avec le fait de créer un modèle réduit. Pourtant la précision des deux propositions n’est pas perdue et nous les comprenons intuitivement.

Prédicat 2 : L’homme communique avec ses congénères via une sémantique non déterministe, pourtant précise et intuitive, permettant de véhiculer des concepts complexes.

On comprend bien pourquoi le vocabulaire utilisé est plus lié au domaine ou aux entités auquel il s’applique qu’au langage lui-même. En effet, le verbe « monter » a un sens différent en fonction de l’objet qu’il met en œuvre.

Prédicat 3 : Le vocabulaire ou le lexique est lié au contexte plutôt qu’au langage et à sa syntaxe. Si le contexte est compris, le vocabulaire l’est aussi.

La complexité d’un langage tient essentiellement à sa grammaire et à sa syntaxe. Si on isole ces deux notions, la communication devient aisée. C’est pour cela que l’apprentissage d’un langage se fait d’abord à l’oral.

Prédicat 4 : Simplifier un langage consiste essentiellement à isoler son utilisateur des règles de syntaxe et de grammaire.

Nous interagissons avec les objets qui nous entourent, au moyen de 3 interfaces au maximum : les attributs de ces objets, leurs fonctions et leurs réactions. Quel que soit l’objet concerné, la définition précise de celui-ci se réduit à ces 3 interfaces. Comme ces interfaces nous sont totalement intuitives, nous les manipulons sans y penser. Les attributs (ou propriétés) sont toujours définis par des substantifs, et leurs valeurs par des adjectifs : « Une table de couleur rouge ». Une table possède une propriété de couleur qui ici, prend la valeur rouge. Les propriétés peuvent être statiques ou dynamiques. Celles qui nous intéressent sont le plus les propriétés dynamiques. A un instant « T », nous sommes beaucoup plus concernés par la vitesse de notre véhicule que par sa couleur. Les propriétés dynamiques reflètent toujours l’état d’un objet et le résultat des fonctions qu’il accomplit.

Les fonctions d’un objet sont toujours définies au moyen de verbes actifs. L’objet « Machine à laver » exécute des verbes tels que : laver, rincer, essorer. Utiliser une machine à laver consiste simplement à utiliser ces verbes. Lorsque c’est le cas, nous observons la progression ou le résultat de ces verbes au moyen de propriétés dynamiques : la température de l’eau, la vitesse du tambour, la position dans le cycle, etc… A noter d’ailleurs que le résultat est toujours une propriété d’un objet : la propreté du linge.

Enfin, lorsque cette machine aura terminé son travail, elle pourra nous prévenir par un signal sonore ou lumineux. Elle envoie une réaction, elle émet un évènement. Elle peut d’ailleurs également le faire dans d’autres circonstances. Par exemple, lorsqu’elle est en panne, elle peut l’indiquer par quelque moyen dont elle dispose. En général un afficheur.

Prédicat 5 : Nous interagissons avec les objets qui nous entourent au moyen de propriétés, de fonctions et de réactions. Toutes notions sur lesquelles se calque notre sémantique : Fonctions = Verbes ; Propriétés = Noms et adjectifs.

 

Simplification du Développement Informatique


Le développement informatique est complexe car il doit générer des systèmes déterministes. Pour ce faire, nous utilisons des systèmes eux-mêmes déterministes.

Ce qui différencie un langage informatique du langage humain, c’est qu’un langage humain n’est jamais déterministe de lui-même, alors qu’un langage informatique l’est toujours.

Cela conduit à plusieurs obligations qui rendent ces langages complexes :
  • La syntaxe et la grammaire doivent être respectées à la lettre (au risque du « Syntax Error » !!!)
  • Le langage possède très peu de mots, ce qui conduit à écrire un grand nombre de phrases potentiellement longues pour véhiculer des concepts simples.
  • Comme tous les termes sont déterministes, pour éviter les écueils du point précédent on habille les langages de librairies de fonctions en très grand nombre (plusieurs milliers de fonctions pour un langage comme le C). L’apprentissage du vocabulaire devient alors une tâche longue, difficile et jamais aboutie.
  • Pour résumer, le nombre de types d’interactions est immense contrairement aux humains qui n’en manipulent qu’un nombre réduit.
Le paradoxe est que la difficulté de création des programmes conduit souvent à des exécutions non déterministes, source potentielle d’erreurs d’exécution et de résultats faux!!!

Le Concept Kallisté permet d’éviter ces écueils.

Comme toutes les idées novatrices, le concept Kallisté est simple et en total paradoxe avec les habitudes des informaticiens. Dans Kallisté, les règles du développement informatique sont réduites aux 5 prédicats évoqués plus haut :
- Limiter les types d’interactions,
- Utiliser une sémantique non déterministe,
- Utiliser un langage qui n’impose pas le vocabulaire,
- Isoler l’utilisateur de toutes règles de syntaxe ou de grammaire,
- Ne manipuler que des objets via leurs propriétés, verbes et réactions.

En clair, il faut utiliser un environnement non déterministe basé sur l’intuition humaine pour créer des systèmes déterministes. Le résultat est le suivant :
- Diminution par 3 des temps et coûts de développement,
- Réduction des intervenants,
- Adaptation à tous les domaines utilisateurs,
- Système non déterminé par concept,
- Permet de sécuriser les développements,
- Aucune erreur de développement possible,
- Erreurs de logique d’exécution uniquement liées au domaine et non pas à l’outil,
- Pas de pré requis,
- Maîtrise du système en moins de 4 heures,
- Pas de langage ni de lexique à apprendre.

Pour illustrer comment le système est utilisé par un opérateur, voici ci-après une copie d’écran du code Kallisté :



Toutes les séquences (paragraphes) d’instructions (de phrases) sont déclenchées par un évènement émis en réaction d‘un objet. Ici lorsque l’opérateur clique le bouton « Boot », celui-ci déclenche une réaction qui exécute la séquence. Dans chacune des phrases, tout ce qui est écrit en noir est généré par le système sans aucune saisie de l’opérateur : pas de règles de grammaire, pas de syntaxe. Tout ce qui est écrit en bleu sont des propriétés d’objets. Elles sont insérées par simple opération de glisser/coller : pas de vocabulaire à apprendre. Tout ce qui est en magenta sont les noms des objets eux-mêmes : pas de saisie. Tout ce qui est en vert sont des constantes : ce sont les seules saisies de l’utilisateur.

- Pas de saisie sauf pour les constantes : donc pas de grammaire, de syntaxe ni de lexique,
- Programme immédiatement lisible et compréhensible par le lecteur car basé sur le langage humain,
- Pas de compilation,
- Pas d’édition de liens.

Cependant, les seules interactions possibles sont les évènements, les propriétés et les verbes. Les phrases sont déterministes même si un même verbe peut vouloir dire deux choses différentes en fonction de l’objet auquel il s’applique.
En interne, le système exécute ce programme via un moteur qui appelle chacun des verbes en lui passant des paramètres via des adresses de propriétés d’autres objets ou des constantes saisies par l’opérateur.
A ce stade, l’innovation principale est donc mise en œuvre, mais elle est encore insuffisante. Elle doit s’accompagner de notions complémentaires permettant de rendre le concept réellement utilisable.

Ces notions complémentaires sont :
- La gestion des types de propriétés et de paramètres de verbes,
- La gestion des propriétés des objets,
- La création de nouveaux objets à partir du néant,
- La création de nouveaux objets métiers à partir d’objets de base,
- Les mises en relations intrinsèques,
- L’exécution toujours concurrente et évènementielle des séquences.

 

La Gestion des Types


Une des difficultés majeures en développement informatique concerne le typage des données. Un nombre peut être un entier, un réel, un complexe, ... Une donnée peut être scalaire, vectorielle, matricielle, … Le développeur n’est jamais isolé de ce typage qu’il doit parfaitement connaître. Le problème se complexifie encore lorsque l’on parle de données évoluées telles que les couleurs, le temps, les textes, …

Dans le Concept KALLISTE, ces problèmes de typages disparaissent.

Dans Kallisté, l’opérateur n’aura jamais à se soucier du type de données qu’il manipule. Le système sera suffisamment intelligent pour traiter ce point. Tous les transtypages possibles ou presque seront implicites.

Il existe un point non traité à ce jour : Le transtypage prédictif.

Convertir un type en un autre n’est pas toujours possible : Il est difficile d’inventer une règle de conversion entre une couleur et une date. Lorsqu’une opération qui demande un transtypage travaille sur des variables, si ce transtypage est impossible, cette impossibilité est découverte à l’exécution : c’est une erreur.

De par sa nature, Kallisté évite cet écueil. Une propriété utilisée comme paramètre d’un verbe et qui possède un type non compatible avec le verbe est identifiée dès l’édition et non pas uniquement à l’exécution car la liaison entre les deux données peut être testée dès l’édition.

KALLISTE, de par sa nature, isole totalement les utilisateurs du cauchemar des types de données informatiques.

 

La Gestion des Propriétés des Objets


Kallisté utilisent des objets. Ceux-ci exposent des propriétés. Elles sont définies par la personne qui a développé l’objet. Dans tous les logiciels existant à ce jour, les propriétés d’un objet constituent un ensemble fini non extensible. En d’autres termes, un utilisateur ne peut pas définir de nouvelles propriétés à cet objet.

Note : Pour les spécialistes de la POO, le seul moyen de créer de nouveaux attributs à une classe est d’en créer une nouvelle qui hérite de la première en la spécialisant. Nous souhaitons briser ce paradigme : Il faut pouvoir spécialiser une classe sans avoir à en hériter.

Ajouter de nouvelles propriétés à un objet peut sembler une idée saugrenue pourtant cela a des implications très importantes dans le domaine de notre métier d’origine : Les essais.

Un objet doit pouvoir être enrichi par l’utilisateur sans avoir à l’éditer et sans même que le créateur d’origine ait la moindre idée de ce à quoi serviront ces propriétés.

Dans le domaine des bus numériques utilisés en avionique l’intérêt de cette fonctionnalité est donné ci-après :

Si l’on reçoit des données de mesures via un tel bus, toutes sont liées à un capteur et à une donnée physique : température, vitesse, accélération, etc…

L’objet qui implémente la lecture des données reçues via un tel bus n’a aucune idée de leur signification. Il produit des données, et c’est alors à un objet externe de les nommer, etc…

L’idée est alors de permettre à l’utilisateur de créer des propriétés : vitesse, accélération, température, etc… et de les lier aux données lues en détaillant leur exploitation.

Ainsi l’opérateur utilisera des propriétés directement liées à son domaine et non pas des propriétés anonymes.

Nous rappelons ce concept : Pour mettre en œuvre les propriétés dynamiques, il faut instaurer un cadre fournit par le noyau de Kallisté sur lequel tout développeur d’un objet pourra s’appuyer pour que cet objet offre ce service de création de propriétés dynamiques.

 

La Création d’Objets


Les objets de base

KALLISTE utilise des objets, on en déduit que les fonctions que Kallisté peut exécuter sont donc uniquement liées aux objets disponibles pour Kallisté.

Nous prévoyons de développer de nombreux objets (une centaine pour la première version). Mais cela ne sera pas suffisant. Il faudra que n’importe quel développeur dans le monde puisse développer des objets pour Kallisté.

Pour cela nous fournirons une API et un SDK. Il ne s’agit pas de modifier, ni d’enrichir le noyau. Cet API et son SDK documentent uniquement les interfaces entre le noyau et les objets.

Ainsi, nous obtenons un couplage faible : Un objet qui présente un problème ne peut pas gêner le noyau et ne peut pas « planter » Kallisté.

Les objets métiers

Cette notion est simple : Un utilisateur crée une application avec Kallisté. Comme cette application est liée à un métier spécifique ou un besoin local, il peut être intéressant de la réutiliser autant que possible dans de multiples contextes.

Comment faire : l’application est transformée en un nouvel objet avec ses propriétés, ses verbes, ses réactions et cet objet pourra être réutilisé dans un nombre infini d’autres applications.

Ainsi chaque utilisateur pourra développer sa propre bibliothèque d’objets sans avoir à développer ceux-ci à partir de zéro.

UDO : User Defined Object.

Bien sûr, cette notion concoure encore à simplifier l’utilisation de Kallisté car chaque UDO définit son vocabulaire sans avoir à tenir compte de l’existant.

Cette idée simple est toutefois complexe à mettre en œuvre en interne du moteur de Kallisté. La raison de cette complexité étant lié au fait que dans un UDO, les liens entre propriétés qui existaient dans une application ne peuvent par tous être conservés. Il faut donc prévoir un cadre de généralisation des propriétés et des verbes.

 

Relations Intrinsèques entre Propriétés


Les relations intrinsèques entre propriétés sont également une notion intuitive qui est rarement mise en œuvre dans les langages informatiques (de par leur structure même). Prenons un exemple : La position de l’aiguille d’un compteur de vitesse d’une voiture est une façon d’exprimer la vitesse de révolution des roues : c’est-à-dire la vitesse du véhicule.

Le compteur a une propriété Vitesse, les roues également. Comme le compteur et les roues sont deux objets différents, ils doivent tous deux implémenter une propriété Vitesse. Pour afficher la vitesse des roues via la propriété vitesse du compteur, il faut attribuer le contenu de la première à la seconde par une phrase dans une séquence. Pourtant dans la réalité il n’y a bien qu’une seule propriété : La vitesse.

Le concept de propriété intrinsèque permet tout simplement de définir une propriété partagée et reconnue par divers objets qui n’ont aucune connaissance entre eux (et qui n’ont pas besoin de savoir qu’ils existent).

La propriété est créée une seule fois par un objet, elle peut ensuite être embarquée dans n’importe quel autre objet. La propriété pourra alors être accessible via n’importe lequel de ces objets. Toute modification du contenu de la propriété est connue de tous les objets la partageant.

Dans les faits, cette simple notion permet de réduire de manière importante le nombre de lignes de code nécessaire dans un programme car beaucoup de ces lignes consistent en des assignations d’un contenu dans un ou de multiples contenants pour mimer le comportement décrit plus haut. La seule méthode ayant été utilisée à ce jour pour contourner cet écueil consiste à mettre en place une base de données temps réel (Temps réel car les données sont mises à jour pour tous les utilisateurs au même moment). Hors, nous savons par retour d’expérience que la mise en place de telles bases de données est complexe.

Dans notre approche, les assignations et les bases de données temps réel deviennent inutiles pour ces besoins. KALLISTE intègre la notion de propriétés intrinsèques de manière native.

Note : Pour les informaticiens, il ne faut pas confondre cette notion avec celle de variable globale. Une variable globale est indépendante de toute autre entité, ici ce n’est jamais le cas. Une propriété intrinsèque est toujours inscrite dans un cadre applicatif dédié à un domaine et n’existe pas seule. Les problèmes liés aux variables globales ne sont donc pas posés.

 

Evènementiel et Concurrence


Ce dernier point concerne l’algorithmique générale d’un programme. La plupart du temps, un grand nombre de lignes de code est utilisé pour la pure gestion de la logique d’exécution de l’application. Sauf dans le cas de spécialistes, la notion d’exécution concurrente est complexe à mettre en œuvre.

De par leur nature, ces deux points sont natifs dans Kallisté. En effet, si l’on considère que toute séquence d’un programme ne peut être exécutée qu’en réponse à la réaction d’un objet, alors l’interface opérateur devient purement évènementielle. Il n’est donc plus nécessaire de coder la logique globale de l’application, on se contente de traiter évènement par évènement. Cela simplifie considérablement le code et respecte notre analyse humaine de ce que fait un programme. A titre d’exemple, et contrairement à tous les autres générateurs d’IHM, il n’est plus nécessaire de rafraichir une IHM sur une horloge. Ce rafraichissement ne se fait que lorsque c’est nécessaire et uniquement pour ce qui est touché. Pourquoi mettre à jour l’afficheur d’un four lorsque la machine à laver a terminé son travail ? C’est une observation idiote, mais c’est pourtant très exactement ce que font les générateurs d’IHM actuels.

La concurrence (ou le multitâche) est une notion simple que nous comprenons aisément. Chaque objet qui nous entoure peut effectuer un travail pendant qu’un autre objet effectue un autre travail. Dans un programme informatique, cette notion est toutefois toujours complexe : Tant au niveau de l’implémentation que de la logique d’exécution.

En ce qui concerne l’implémentation, dans Kallisté la question ne se pose pas du fait même de la gestion évènementielle. En d’autres termes, le multitâche est natif, standard et ne réclame aucune action particulière de la part de l’utilisateur.

La logique quant à elle se résume à dire qu’une propriété ne peut être sollicitée par deux objets en même temps pour être lue ou écrite. Le noyau est conçu pour cela : chaque propriété est elle-même un sémaphore qui accepte ou met en attente un accès. Donc la logique même de gestion des accès concurrents est prise en charge par le noyau.

Tous les programmes dans Kallisté sont évènementiels et multitâches de manière native sans intervention spéciale des utilisateurs

 

Conclusion


Si le concept de la programmation non déterministe et sa mise en œuvre constitue la principale innovation de Kallisté, il faut également bien comprendre que tous les autres notions abordées, prises indépendamment les uns des autres sont toutes enrichies par rapport à l’existant. Des systèmes intègrent certaines de ces notions. Ce qui ici est entièrement nouveau, c’est le fait que toutes ces notions coexistent dans un même environnement et qu’elles contribuent à améliorer l’innovation majeure qui consiste à rendre la programmation intuitive.

Le concept global de Kallisté repose sur la programmation intuitive.