Vers l’intégration de causes et contraintes : interpréteur des réseaux de Petri enrichis avec la programmation logique

Encadrants : 

Occurrences : 

2016

Nombre d'étudiants minimum: 

4

Nombre d'étudiants maximum: 

6

Nombre d'instances : 

1

Domaines: 

Un problème qui a été récemment souligné dans la littérature est la confusion assez diffuse en computer science et IA concernant les notions de règle réactive et de règle déclarative. En gros, cette distinction reproduit la différence existant parmi dépendances causales et dépendances logiques. Les premières spécifient les changements qui sont en général irréversibles, tandis que les deuxièmes établissent des contraintes qui peuvent être interprétées comme des transformations réversibles (il suffit de restaurer les entrées).

L'intuition motivant ce projet est que lorsqu'on décrit un phénomène réel, ces deux composantes sont également nécessaires. En ingénierie, par exemple, on sépare l'étude des états stationnaires de l'étude des états transitoires (qui peuvent conduire à des états stationnaires), mais les deux doivent être effectués si on veut procéder à une étape de production. De la même manière, le contenu de narrations consiste souvent en une séquence d'événements qui produit des changements, mais qui est exprimée (normalement sous forme linguistique) d’une manière qui comporte des contraintes logiques.

Description

L'objectif de ce projet est de réaliser un interpréteur pour un langage de modélisation simple qui distingue bien, mais réunit d’une façon opérationnelle les deux aspects. Il pourra être utilisé, par exemple, pour modéliser et simuler des scénarios. On s'appuiera sur deux domaines bien établis: les réseaux de Petri pour la partie procédurale/réactive, et la programmation logique (ASP) pour la partie liée aux constraintes et à la logique déclarative.

Important :

  • L'interprétation de la partie logique sera traitée en utilisant un des solveurs ASP déjà existants.

  • On commencera avec le cas propositionnel, pour passer au cas des prédicats dans un deuxième temps.

Travail

Le travail sera divisé dans les fonctions suivantes :

  • parseur des programmes écrit dans un langage de modélisation cible,

  • décoration du réseau associé,

  • exécution complète du réseau (en considérant toutes les branches),

  • s’il y a la possibilité, visualisation statique du modèle, animation.

Il y a de l’espace pour des améliorations liées à la syntaxe/sémantique.

A priori, le développement devrait être en Java (ou dans un autre langage qui compile sur JVM, comme Groovy, Scala, Erlang) pour meilleure reusabilité, ou bien C/C++ pour meilleures performances (voir traitement native de concurrence), mais, avec de bons arguments vous pourrez proposer d’autres langages aussi.

Exemple de modèle issu d’une narration

% crywolf story
-> crywolf, peoplehelp, laugh, crywolf, peoplehelp, laugh, whitewolf, crywolf, neg peoplehelp, cry.

% crywolf mechanisms
wolf -> crywolf.
crywolf in neg joker -> peoplehelp.
(crywolf in neg wolf) seq (crywolf in neg wolf) -> joker.
peoplehelp in neg wolf -> laugh.
crywolf seq timeout1 in neg peoplehelp -> crywolf.
wolf seq timeout2 in neg peoplehelp -> cry.

% crywolf taxonomy
wolf :- whitewolf.