Un langage de composants avec protocoles basé sur le modèle des Symbolic Transition Systems

1. Un langage de composants avec protocoles basé sur le modèle des Symbolic Transition Systems Robin Passama – équipe OBASCO (EMN/INRIA)

2. Mes Centres d’Intéret • Conception de langages • Composants logiciels • Intégration de modèles formels (e.g. réseaux de Petri à objets) dans les langages (exécution) • Aspects méthodologiques • Conception d’architectures robotiques. • MDE pour la création de langages dédiés

3. Robotique & Domotique : Besoins • Methodologies : • pour garantir la fiabilité du logiciel • pour augmenter la productivité (réutitilisation, lignes de produits, etc.) • pour maintenir l’évolutivité du logiciel fâce à un developpement technologique rapide • Outils : • automatisant les tâches de développement • procédures de vérification/validation • adaptés aux terminologies/concepts des experts

4. Quelques Directions Actuelles • Vers la formalisation des propriétés pour la vérification/validation • utilisation de modèles formels (Réseaux de Petri, logique temporelle, réseaux de contraintes, etc.) • Aspect central : planification, ordonnancement et synchronisation de tâches concurrentes • Vers la réutilisation du code/des modèles • utilisation des techniques de génie logiciel (MDE, lignes de produit, composants, DSL, etc.) • Aspect central : composition « sure »

5. Les problèmes à gérer en parallèle • Concurrence : aspect fondamental des systèmes domotiques & robotiques • synchronisation des processus (e.g. dépendances temporelles entre tâches de perception et de commande) • simultanéité des activités (e.g. robotique coopérative) • Composition : modulatisation des systèmes, réutilisation • vérifier la composition un langage de composants avec protocoles

6. /A := 0:int I think ? T:int /A := T end E [A==S] use ? S:int T • La base de départ : un modèle formel • Les Symbolic Transition Systems (STSs) • diagramme d’état transition • gardes & emissions/récceptions de valeurs • type de donnée STS du processus

7. La base de départ : un modèle formel • description de synchronisations • production de vecteurs de synchronisation givet ! T:int / T:=(T+1)%MAXINT /A := 0:int / S,T,C:= 0:int I think ? T:int /A := T S end E [C==0] gives ! S:int / C := C +1 [A==S] use ? S:int T end / S:=(S+1)%MAXINT C:=C-1 STS du processus STS du serveur

8. La base de départ : un modèle formel • description de synchronisations • production de vecteurs de synchronisation : 3 vecteurs pour un serveur et un processus ( end, end ) (gives, use ) (givet, think ) • ( serveur , processus )

9. La base de départ : un modèle formel • création du modèle sémantique global • produit synchrone • analyse : ADL Korrigan • propriété de sureté, logique modale [Poizat & Royer, JUCS 06] • absence d’interblocages, logique temporelle [Royer, IASSE’04] • analyse de mailbox, algorithme dédié [Poizat & al., FMOODS, 2006] S,I (givet ! T:int / T:=(T+1)%MAXINT, think ? T:int /A := T) (end /S:=(S+1)%MAXINT; C:=C-1, end) S,E ([C==0] gives ! S:int / C := C +1, [A==S] use ? S:int ) S,T

10. Objectif : un langage de composants avec protocoles basé sur les STSs • gérer des synchronisations « complexes » • simultanéité de l’exécution • plusieurs participants (rendez-vous multiple) • modèle de composition • « souplesse » de réutilisation des composants • analyse des compositions

11. Première étape : un framework d’exécution • vue d’ensemble STS objet passif objet actif Protocole STS encodé dans des objets du framework Classe java implantant le type de donnée appelle Interface Java synchronise Arbitre objet partagé

12. Première étape : un framework d’exécution • préoccupation principale : réaliser les synchronisations • synchroniser les événements en fonction des états & gardes des transitions • simuler la simultanéité (zone de synchronisation) • préoccupation secondaire : optimiser la concurrence entre STSs • découpler l’exécution des synchronisations indépendantes • limiter les accès concurrents

13. Arbiter + isSynchronous() : int + isPossible() : boolean + checkGuards() : boolean • Première étape : un framework d’exécution • premier prototype Java [CPA, 07] Runnable STS LockSynch #synchro : int[] #synchValueNumber : int # counter : Counter 1..1 1..* #target : int[][] #t : Thread #currentState : int arbiter 1..1 1..* + eval() : void + run() : void + chooseAction() : void + synchronizeOnEntry() : boolean + synchronizeOnExit() : void 1..1 transitions conflict 1..1 * Expression Conflict Flags 1..* 1..1 # sharedcounter : Counter #counterset : Counterset # actionName : String # eventName : String # guardName : String # emitterName : String # access : boolean [] # sharedCounters : Counter[] + isFree() : boolean + freeze(Counterset) : boolean + relax() : void + isEmitter() : boolean

14. Arbiter + isSynchronous() : int + isPossible() : boolean + checkGuards() : boolean Première étape : un framework d’exécution Runnable teste si les synchronisations sont globalement possibles en fonction de l’état des STS STS #target : int[][] #t : Thread #currentState : int arbiter 1..1 états et transitions du diagramme 1..* + eval() : void + run() : void + chooseAction() : void teste si les gardes des transitions à synchroniser sont vérifiées transitions Expressions portées par les transitions * Expression # actionName : String # eventName : String # guardName : String # emitterName : String + isEmitter() : boolean

15. Première étape : un framework d’exécution • Barrière de synchronisation (idée générale) vecteur de synchronisation synchronized public boolean synchronizeOnEntry(){ //not last thread if (synchronization possible en fonction de l’état global) if(counter < synchValueNumber){ if (synchronisation pas en conflit){ counter.inc(); //one more try { wait();} catch (InterruptedException e){} } } else {//the last one counter.reset(); notifyAll();//wake up all return true; } return false; } LockSynch # synchro : int[] #synchValueNumber : int # counter : Counter + synchronizeOnEntry() : boolean + synchronizeOnExit() : void

16. Première étape : un framework d’exécution gestion des conflits d’un verrou de synchronisation (LockSynch) contrôle l’accès aux compteurs partagés compteur du nombre de STS synchronisés, partagé avec LockSynch Conflict Flags 1..* 1..1 # sharedcounter : Counter #counterset : Counterset # access : boolean [] # sharedCounters : Counter[] + freeze(Counterset) : boolean + relax() : void synchronized + isFree() : boolean teste si l’accès aux compteurs de synchronisation est possible et si oui bloque l’accès teste si une synchronisation en conflit n’est pas déjà démarrée ensemble de compteurs des synchronisations en conflit permet de s’assurer que l’état des compteurs ne va pas changer avant que isFree soit effectivement appelée.

17. Première étape : un framework d’exécution • Relation type de données / protocole • Nommage des éléments des expressions Nom de référence de l’événement Processus constructor think ? T:int / thinkAction(int T) I end / endAction() E Nom de référence de l’action T [checkUse(int S)] use ? S:int /useAction() Nom de référence de la garde

18. Première étape : un framework d’exécution • Relation type de données / protocole • Utilisation de l’API réflexive Java public boolean guard(); public Type emitter(); public void action(); [guard] event ! emitter:Type / action STS #target : int[][] #t : Thread public boolean guard(Type var); public void action(Type var); [guard] event ? var:Type / action + eval() : void + run() : void + chooseAction() : void public class Processus extends DataPart implements IProcessus{ protected int A; public Processus(){A = 0;} public void thinkAction(int T){A = T;} public boolean checkUse(int S){return A == S;} public void useAction(int S){//do nothing} public void endAction(){//do nothing} } 1..1 #dataPart Data Part + executeAction() : void + executeGuard() : boolean

19. Première étape : un framework d’exécution

20. Première étape : un framework d’exécution

21. Première étape : un framework d’exécution • premier prototype opérationnel • communication réseau • utilisation RMI • gestion des exceptions • retour à l’état précédent ? • comment gérer les exceptions levées lors d’une synchronisation ? • preuve du bon fonctionnement du support ? • modèle CSP des moniteur Java

22. Deuxième étape : un modèle de composants • types de composants • primitifs (contenant un STS) • composites (contenant une architecture) • propriété commune : les ports • un port correspond à un événement levé • synchrone ou asynchrone • initiative dans l’interaction • connexions • n-aire (communication :1-à-n) • calcul automatique des vecteurs de synchronisation

23. Deuxième étape : un modèle de composants Port Component interface 2..* # synchronous : boolean # initiative : {originate, undergo, mixed} # eventName : String 1..* 2..* Primitive Composite # protocol : STS # dataPart : DataPart Connection # glue : GlueDefinition 1..* Glue permettant de définir les vecteurs de synchronisation

24. Deuxième étape : un modèle de composants • Définition de la glue des connecteur : quel modèle ? • expression directe des vecteurs de synchronisation • « langage » de description de la glue basé sur des opérateurs logique (AND, XOR, etc.) ? • plus pratique pour l’utilisateur • automates ? [Canal, Poizat & Salaun, FMOODS 2006, CAL2006] • meilleure d’adaptation/réutilisation des composants lors d’incompatibilité comportementales (réordonnacement) • générer des STSs « adapteurs » ?

25. Deuxième étape : un modèle de composants p1 : Processus port synchrone « initiateur » (originate) think ? T:int / thinkAction(int T) port synchrone « mixte » (mixed) I port synchrone « esclave » (undergo) end / endAction() E s.givet AND (p1.use XOR p2.use) vecteurs: (givet, - , use), (givet, use, -) [checkUse(int S)] use ? S:int /useAction() T use end think s : Serveur givet givet ! T:int / incT() gives S end use end think end / endAction() [C==0]gives ! S:int / incC() p2 : Processus

26. Deuxième étape : un modèle de composants • Vers la gestion du cas asynchrone • traduction dans le modèle synchrone • génération de proxies synchronisation avec le receveur synchronisation avec l’émetteur I réception du message / mémorisation du message initialisation du buffer I MR FE relaie du message émit / message retiré du buffer réception du message émit / bufferisation du message émission du message proxy receveur proxy émetteur

27. Troisième étape : définition de la syntaxe du langage • BNF (en cour de défintion) ComponentDescription ::= COMPONENT Ident [Parameter] Interface Content END Interface ::= INTERFACE Port* ENDINTERFACE Port ::= PORT IdentPort SynchProfile EventName InitiativeProfile [Communication] Communication ::= ! (Ident : IdentType)* | ? (Ident : IdentType)* SynchProfile ::= SYNCH|ASYNCH InitiativeProfile ::= ORIGINATE|UNDERGO|MIXED Content ::= Protocol|Architecture Protocol ::= PROTOCOL States Transitions DataType ENDPROTOCOL States ::= STATES (IdentState[INITIAL])* Transitions ::= TRANSITIONS (IdentState TO IdentState [Guard] EventName [Communication] [ActionName])* Architecture ::= ARCHITECTURE SUBCOMPONENTS (ComponentIdent)* LOCAL (LocalIdent : ComponentIdent)* CONNECTIONS Connection* [BINDINGS Binding*] ENDARCHITECTURE Connection ::= CONNECT (LocalIdent.IdentPort)* USING ConnectPattern Binding ::= IdentPort -> LocalIdent.IdentPort DataType ::= IMPLEMENTED BY IdentJava ...

28. Troisième étape : définition de la syntaxe du langage • Réflexions actuelles • Possibilité d’associer différentes implantation Java • quand se fait le choix ? (création du type ou de l’instance) • Description des connexion • types de connexion ? (prédéfini ou non) • Quelle notation ? (dépend du modèle) • Lien avec l’ADL Korrigan (modèle algébrique-Java)

29. Quatrième étape : le compilateur • Pas encore réalisé • compilation protocoles vers code framework • configuration des objets partagés • traduction des connexions sous la forme d’ensemble de vecteurs de synchronisations • Traduction des composition de composites en compositions de STSs

30. Quatrième étape : le compilateur • Test de compatibilité • interface / protocole : utilisation compatibilité interface Java (générée à partir protocole)/ classe Java • protocole / code : difficile si modèle algébrique Korrigan intégré au protocole • Problème de la distribution • distribution des objets partagés (LockSynch, Flags, Arbitre ...) ? • décomposition des objets partagés ? • eviter d’avoir un goulot d’étranglement (Flags, Arbitre)

31. Conclusion • Objectif : prototype complet d’ici l’été • support d’exécution • compilateur minimaliste • Des outils plus avancés ? • IDE • traduction système vers modèle sémantique • vérification/validation (lien avec Korrigan) • Confrontation à un exemple concret • projet AMPLE (lignes de produit logicielles pour la domotique)