Un langage de programmation contextuel, à interfaces multiples
On est focusé actuellement sur la possibilité pour un programme de fonctionner dans des contextes différents, avec des interfaces différentes.
Plusieurs infrastructures ont été décrites, indépendamment les unes des autres, et conçues de façons différentes, mais qui se rejoignent quand au but essentiel.
L'exemple le plus couramment donné pour justifier cette recherche est le cas du test des programmes. Si celui-ci a une interface graphique, il est difficile de réaliser un script pour automatiser les tests et traiter tous les cas d'utilisation possibles. Mais si le programme dispose d'un double système d'interface, on peut faire usage de tels scripts, avec une interface en ligne de commande qui leur conviennent.
On peut y voir aussi une application dans le domaine de la robotique qui permettrait d'accélérer considérablement l'apprentissage par des machines. Le logiciel qui fait fonctionner le robot disposerait d'une part d'une interface avec le matériel, et d'autre part avec une version virtuelle du robot sur un écran. Le formateur pourrait alors développer le comportement du robot sur l'ordinateur, avec le même programme qui fait agir la machine réelle.
L'architecture nette pour un logiciel
La "Clean Architecture". Le programme traduit le fonctionnement d'une activité avec des objets représentant ceux du métier, mais il est indépendant des frameworks, de l'interface utilisateur, des bases de données. Ils sont chacun interchangeables, une interface par une autre, un gestionnaire de base de données par un autre.
Le programme peut être testé avec une interface de test.
On représente cette architecture par des cercles concentrique, avec au centre le programme qui dépend entièrement de l'activité pour laquelle on fait un traitement informatique.
Le second cercle est l'ensemble des cas d'utilisation. Ils sont formalisés par d'autres programmes qui font appel au programme central, mais n'influencent pas sa conception.
Le troisième cercle est un ensemble d'adaptateurs pour les interfaces. Ils reçoivent des données et les formattent pour être traitées par le cercle intérieur, le second. Cela fonctionne dans le sens inverse.
Le quatrième et le plus externe des cercles comprend les frameworks, les bases de données, les interfaces utilisateurs.
Cette architecture peut répondre à notre besoin de programme unique à contextes multiples, cependant elle est assez générale, il reste encore à définir comment l'implémenter et elle n'a pas de rapport avec le langage de programmation, mais seulement avec les programmes de l'application.
L'architecture hexagonale
Ou "Hexagonal Architecture". Elle comporte aussi des figures concentriques, mais ici ce sont des hexagones. L'hexagone central est l'application. Il est inclu dans un second qui est l'ensemble des adaptateurs. Comme dans le cas précédent, il préparent les données pour les faire transiter dans les deux sens entre l'application et les outils externes. Ceux-ci sont les frameworks, les bases de données, les interfaces utilisateurs.
Elle prévoit aussi d'avoir une interface spéciale pour les scripts en batch de test, ils sont liée à l'application par un adaptateur spécifique tandis qu'une interface utilisateur à aussi son adaptateur.
La notion d'hexagone à un lien avec l'implémentation de l'infrastructure. Chaque facette correspond à un port. Un port a un protocol pour communiquer avec un type d'agent. Les adaptateurs ont un port pour communiquer avec la base de données, un port pour l'interface. Le programme central a des ports pour communiquer avec chaque adaptateur.
La figure hexagonale est en fait symbolique. Le nombre de facettes dépend du nombre de port, il n'y en a pas forcément 8, c'est une figure de principe.
En ayant posé le principe de port, on s'est rapproché de l'implémentation. Un port peut être une méthode d'un objet, et un objet dispose de méthodes pour chaque port.
Le problème de la robotique se résoud donc avec un port dédié au robot concret, un autre au robot virtuel. Ce dernier est relié à un framework qui ajoute programmatiquement les lois de la physique (pesanteur, collision) aux mouvements du robot.
Avec l'architexture hexagonale, on en reste encore à l'utilisation des langages de programmation classiques. Mais les choses peuvent changer avec l'architecture DCI.
DCI, interaction contextuelle des données
DCI, ou Data Context Interaction, veut réécrire l'orientation objet des programmes pour remplacer les objets par des rôles, plus adaptables et génériques. Parce que les objets conviennent pour représenter les structures, mais pas le système en action. Ils sont statiques alors que l'on veut représenter virtuellement un monde en mouvement.
DCI peut être vu comme un complément au Model View Controller (Modèle vue-contrôleur), c'est en fait la même personne, Trygve Reenskaug qui est considéré comme étant à l'inventeur des deux modèles.
Les données sont tous les éléments qui décrivent un système. Ces données sont représentées par des objets qui reprennent en fait la représentation mentale que le programmeur ou l'expert en ont. Mais utilisées dans des domaines différents, ces mêmes données auraint des représentations, et donc des objets différents. Il faudrait donc déplacer de l'objet à l'instance tout ce qui est contextuel et qui dépend de l'utilisation que l'on en fait.
Pour ce faire on crée des rôles. Un même objet a plusieurs rôles qui correspondent à des utilisations différentes. Un rôle a des méthodes, propres à l'utilisation. Mais il est générique, il s'applique à des variables abstraites.
Et l'action, la dynamique du système? L'action est représentée par les rôles.
Selon le concepteur de DCI, si la notion de rôles n'a pas été adoptée dans la programmation (au contraire du modèle MVC), c'est parce que les langages sont orientés vers les classes plutôt que vers les objets. (Ref: Trygver). Les classes décrivent des modèles conceptuels et leurs propriétés, mais elle ne capturent pas leurs interactions, ni le système complexe qui en résulte. Celles-ci pourraient se faire par échanges de messages qui seront déterminés par la contribution à un but, et une contribution qui est adaptée au contexte.
Même si les rôles peuvent être représentés avec les langages actuels, c'est quelque chose qui devrait être ajouté nativement à un nouveau langage, comme construct indépendant. L'auteur a essayé de réaliser cela avec BabyUML.
Il se base sur UML, un modèle qui se définit ainsi: programme = structures de données + algorithmes + communication.
Les données sont représentées par des objets, mais le programmeur décrit aussi la communication entre ces objets. Enfin, les algorithmes sont les traitements sur les données résultant des demandes.
Un des aspects intéressants du système de Reenskaug est dans cette phrase:
Un univers d'objets qui existent dans l'espace et le temps et où les objets apparaissent et disparaissent selon les besoins.
Cela convient bien à la robotique, car le robot est dans un monde en évolution, et non un univers qui recommence à chaque fois que l'on met le robot en marche, comme cela se passe avec les programmes pour ordinateurs.
De DCI on doit retenir que la communication entre objets, qui fait qu'un système est tel, doit se formaliser indépendamment des objets. Par exemple on peut décrire une activité comme un échange de messages entre des objets, chacun étant envoyé à partir des informations dont il dépend. Cela peut s'implémenter avec les méthodes des objets, mais idéalement, et c'est le principe des rôles, cela serait implémenté séparément, en tant que méthode de rôle. Un objet peut alors être superposé à un rôle pour participer à une tâche ou à l'accomplissement d'un but.
En conclusion, les langages de très haut niveau du futur, plus particulièrement s'ils veulent être adaptés à la robotique, et ce sera le cas de Scriptol II, devront passer à un modèle de représentation différent de celui des classes et objets, qui soit plus dynamique, et propre a représenter la connaissance sur un monde concret fait d'interactions.
Corrélativement il faudra une vaste mémoire pour stocker cette représentation constamment mise à jour d'un monde dynamique et en évolution.
Par Denis Sureau le 4 janvier 2014.