Telecom ParisTech INF722 – Thomas Robert page 1 Modélisation des activités concurrentes ---------------------------------------------------- Produits d'automates.

Présentation au sujet: "Telecom ParisTech INF722 – Thomas Robert page 1 Modélisation des activités concurrentes ---------------------------------------------------- Produits d'automates."— Transcription de la présentation:

1 Telecom ParisTech INF722 – Thomas Robert page 1 Modélisation des activités concurrentes ---------------------------------------------------- Produits d'automates et Réseaux de Petri Objectifs Synchronisation vs Echange de messages Produits d'automates Réseaux de Petri

2 Telecom ParisTech INF722 – Thomas Robert page 2 Représentation d'un système et réutilisation Système = composition d'un { programmes } Question : Doit on réécrire un automate chaque fois ? Idée : mettre en place des règles pour déduire l'automate d'un système à partir de ceux de ses modules

3 Telecom ParisTech INF722 – Thomas Robert page 3 Modéliser des « thread » et parallélisme Rappel : un automate représente une exécution séquentielle Question : comment représenter l'exécution d'un système « multi-threadé » potentiellement réparti ? Idée : un automate par activité séquentielle Mais : et si les activités ne sont pas indépendantes

4 Telecom ParisTech INF722 – Thomas Robert page 4 Bilan Un systèmes : plusieurs éléments qui « coopèrent » potentiellement en parallèle Les propriétés à prouver : Comment valider l'évolution conjointe de plusieurs programmes ? Par exemple : comment prouve-t-on l'absence d'interblocage ? Difficulté : quel modèle d'interaction doit on utiliser entre deux modèles séquentiels La synchronisation forte (rendez vous ) La transmission asynchrone de message

5 Telecom ParisTech INF722 – Thomas Robert page 5 Sens pratique Communcation Synchrone vs Asynchrone

6 Telecom ParisTech INF722 – Thomas Robert page 6 Sens pratique Communcation Synchrone vs Asynchrone

7 Telecom ParisTech INF722 – Thomas Robert page 7 Réseaux d'automate, Produits et communications Principe : On met en parallèle plusieurs automates interagissant par synchronisation de leurs transitions => Un automate doit pouvoir ne rien faire => La synchronisation se fait sur transition Pouvoir ne rien faire : une action neutre  pour (s,  Hypothèse et notations : Soit deux automates A1 et A2 tels que A1=(I1,Q1,∑1,∆1,F1),A2=(I2,Q2,∑2,∆2,F2) Avec Q1 Q2 disjoints Et Pr(∑,tr) la projection d'une trace sur ∑ (c'est à dire, pour tout symbole s de tr absent de ∑, s → 

8 Telecom ParisTech INF722 – Thomas Robert page 8 Sémantique du produit synchronisé Un trace tr est acceptée par le produit A1xA2, ssi Pr(∑1,tr) est acceptée par A1 et P(∑2,tr) par A2 Il existe une séquence de transitions (q1,q'1) →(q2,q'2) → … → (qk,q'k) telle que pour tout i, la transition t: (q p,q' p ) tr p (q p+1,q' p+1 ) existe si et seulement si – Si tr p est dans ∑1 et ∑2 alors (qp,tr p,q p+1 ) est dans ∆1 et (q'p,tr p,q' p+1 ) est dans ∆2 – Sinon soit q' p == q 'p+1 et (qp,tr p,q p+1 ) est dans ∆1. soit q p == q p+1 et (q'p,tr p,q' p+1 ) est dans ∆2.

9 Telecom ParisTech INF722 – Thomas Robert page 9 Exemple d'un serveur pouvant traiter jusqu'à 2 requêtes en parallèle Système : un serveur de données Propriété à prouver : absence d'impasse (le serveur peut toujours revenir dans son état où il n'a aucune requête a traiter Si une requête est acceptée par le serveur, le client finit toujours par obtenir la donnée attendue Les actions coté client : request, result, reject Les actions coté serveur : request, result, reject, start_process, end_process

10 Telecom ParisTech INF722 – Thomas Robert page 10 La logique avec branchement CTL Les formules de CTL sont définies par la grammaire suivante : Φ,Ψ ::= p | q |... | true | false (propositions atomiques) Φ∧Ψ | Φ∨Ψ | Φ⇒Ψ | ¬Φ | (connecteurs booléens) EFΦ | EGΦ | EΦUΨ | EXΦ | AFΦ | AGΦ | AΦUΨ | AXΦ (connecteurs temporels) E, A: quantifications sur toutes les exécutions possibles à partir de l’état courant Les formules sont interprétées sur des états de notre modèle, et non sur une exécution (« formule d’état » vs. « formule de chemin »)

11 Telecom ParisTech INF722 – Thomas Robert page 11 Sématique de E et A Ces formules s’interprètent sur l'ensemble du système à transitions (ie structures de Kripke) et non un chemin de la structure Soit succ*(q) : l'ensemble des successeurs d'un état q dans une structure de Kripke K E R: il existe un futur où R est prouvée dans K A R : tous les chemins de K prouvent R

12 Telecom ParisTech INF722 – Thomas Robert page 12 Exercice Définir la propriété équivalente à : Le serveur doit s'assurer qu'à partir du moment où une requête est reçue, et que quelque soit le chemin d'exécution : - Soit la requête est acceptée et le serveur doit finir par émettre le résultat - Soit le serveur traite déjà deux requêtes et la requête est rejetée immédiatement

13 Telecom ParisTech INF722 – Thomas Robert page 13 Les réseaux de Petri

14 Telecom ParisTech INF722 – Thomas Robert page 14 Les réseaux de Petri Principe : représenter la notion d'activité comme une partie de l'état du modèle Démarche : utiliser une sémantique intégrant directement la synchronisation (transitions complexes) ou transmission de messages (ressources) Un réseau de Petri c'est un ensemble de « place » permettant d'identifier les ressources. Une place contient un nombre de jeton déterminant le nombre de ressources Des transitions permettant d'exprimer des lois de consommation/production multiples de ressources

15 Telecom ParisTech INF722 – Thomas Robert page 15 Rdp : Sémantique Un réseau de Petri est défini : L'ensemble de ses places (ou sites) P L'ensemble des noms de transitions T={t1....tn} L'ensemble des règles de « consommation » dit préconditions Pre : PxT → Nat (fonction donnant un entier pour chaque couple place -transition) L'ensemble des règles de « production » dit post- conditions : Post : PxT → Nat Etat et initialisation : L'état d'un réseau de Petri est appelé marquage et appartient à Nat^(|P|), un entier représentant le nombre de ressources disponibles en chaque P

16 Telecom ParisTech INF722 – Thomas Robert page 16 Transition, franchissement et séquences d'exécution Notation M(P) : valeur du marquage de P. Une transitions t est franchissable ssi : ∀ P, Pre(P,t) ≤ M(P), on le note M [t> M' avec M' le nouveau marquage atteint suite au franchissement de t. le nouveau marquage M' vérifie ∀ P M'(P) = M(P)+(Post(P,t)-Pre(P,t)) On dit qu'une séquence de transitions σ = σ't est franchissable à partir du marquage M si: σ' est franchissable à partir de M et M [σ'> M' t est franchissable à partir de M', M' [t> M''

17 Telecom ParisTech INF722 – Thomas Robert page 17 Notion de marquage accessible On dit qu'un marquage M est accessible dans le réseau R si et seulement si il existe une séquence de transitions σ telle que M0 [σ > M. M0* représente l'ensemble des marquages accessibles depuis M0 Un invariant du réseau de Petri I est une équation sur les valeurs du marquage telle que tout marquage de M0* vérifie cet invariant.

18 Telecom ParisTech INF722 – Thomas Robert page 18 Représentation matricielle de Pre et Post : PRE i,j = Pre(p i,t j ) POST i,j = Post(p i, t j ) Matrice d'incidence (Inc =POST-PRE) Inc i,j représente la variation du nombre de jetons dans la place pi, si l'on tire la transition tj une fois. Inc i,j: Post(pi,tj)-Pre(pi,tj), soit Inc -,j la j-ème colonne de Inc M [t j > M' se traduit par M'=M+ Inc -,j Modéliser l'impact d'une séquence σ sur M : σ se transforme dans le vecteur tc tel que pour toute transition t j =#occurrence de t j, alors M'=M+ Inc * tc Réprésentation matricielle (détail)

19 Telecom ParisTech INF722 – Thomas Robert page 19 Les propriétés clés du réseau de Petri Borné : Le réseau de Petri est borné si l'on peut prouver qu'il existe un entier K, tel que pour tout M dans M0* alors pour toute place p M(p)≤K. Remarque : si le réseau n'est pas borné, cela signifie que son marquage peut diverger (représenter un nombre infini de ressources) Méthode pour prouver la propriété : construire le système à transition (Q=M0*, ∆ ={(M,tM') tels que M [t> M'})

20 Telecom ParisTech INF722 – Thomas Robert page 20 LTL et réseau de Petri Les formules == des contraintes sur le marquage Exemple : spécifier la propriété, On considère le système de production consommation de messages : Prop1 : A partir du moment où le producteur a produit 3 messages sans consommation, le producteur doit attendre que le consommateur en utilise au moins 1

21 Telecom ParisTech INF722 – Thomas Robert page 21 Quelques mots sur l'extension stochastiques Vision numéro 1 (taux et normalisation): A chaque transition est associé un taux d'activation une fois la transition active : ce taux permet de modéliser la distribution des valeurs possibles de la durée séparant l'activation et le franchissement de la transition. Si deux transitions sont en concurrence, la comparaison des taux indique laquelle des deux transitions sera tirée avant l'autre et avec quelle probabilité

22 Telecom ParisTech INF722 – Thomas Robert page 22 Du temps continue au temps discret Soit P tel que M(P) =1 active t et t' de taux u1 et u2. SI l'on ne s'intéresse pas à la valeur précise de l'instant de tirage, alors il est possible de calculer Pr(tirage (t) < tirage (t »)). (Pr : probabilité) Un exemple (outil pipe modèle stochastique)...