1 / 55

Chapitre 5

Chapitre 5. SDL et MSC. w3.uqo.ca/luigi. Modèles à états étendus. Nous avons décrit plusieurs méthodes de description de protocoles, mais nous avons parlé surtout de l’aspect contrôle

trinh
Télécharger la présentation

Chapitre 5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapitre 5 SDL et MSC w3.uqo.ca/luigi

  2. Modèles à états étendus • Nous avons décrit plusieurs méthodes de description de protocoles, mais nous avons parlé surtout de l’aspect contrôle • Dans les machines à états finis, dans le LOTOS de base, on ne peut communiquer que des messages avec un très petit vocabulaire • Des constantes • Les protocoles transportent des données, et prennent des décisions sur la base de ces données • Les modèles d’états doivent donc été étendus pour représenter les données • Utilisation de variables

  3. Les variables comme abréviations • Les variables représentant les données peuvent être enlevées mais la machine à états pourrait devenir infinie ?4 ?1 ?3 ?2 ?x !1 !4 !3 !2 etc . . . !x Machine équivalente qui n’utilise que des constantes (c’est une machine infinie…). Elle restera finie si on fait une hypothèse sur la valeur max de x, p.ex. 4 Machine à états qui accepte une valeur pour une variable x (disons un entier) et l’émet ensuite

  4. EFSM models, extended finite state machines • Pour cette raison, tout formalisme de description de protocoles utilise les variables • On parle donc de extended state models • SDL est le mieux connu • ESTELLE fut développé par l’ISO en parallèle avec LOTOS et est encore utilisé • Il est semblable à l’SDL mais utilise le langage Pascal comme base • Il y a aussi des autres langages pour les EFSMs, mais ils ont été d’utilisation beaucoup plus limitée

  5. Introduction à SDL

  6. Histoire • SDL est une norme de l’UIT-T (ou en anglais ITU-T) • Specification and Description Language • Le projet fut amorcé par le CCITT (ancien nom de l’ITU) en 1972 • L’idée était de créer un langage pour la description des protocoles de signalisation téléphonique • Vers la fin des années 1980, le langage fut étendu pour pouvoir spécifier les protocoles, surtout OSI • Comme toutes les normes ITU, le langage est révisé tous les quatre ans • Cependant les révisions sont toujours compatibles, donc ce que vous pourriez apprendre sur les vieilles versions est encore valable

  7. Développement • Au début (1972) SDL était un simple formalisme graphique pour spécifier les machines à états finis des protocoles téléphoniques • Relativement simples à cette époque • En 1984, on ajouta les processus et les données • SDL 1988 vit une stabilisation sur laquelle on a bâti ultérieurement • En 1992 on ajouta l’orientation objet • En 1996 on ajouta • ASN.1, une notation pour la spec des structures de données • et les Message Sequence Charts • Aujourd’hui SDL et MSC sont deux notations intégrées • À partir de SDL2000 il y a eu un effort d’intégration avec UML • Peu de changements dans les dernières années

  8. Utilisation et outils • À cause de la grande autorité de l’ITU, le langage fut bientôt adopté par l’industrie des télécom, cependant encore aujourd'hui il y a peu de boîtes qui l’utilisent à fond • Elles sont surtout en Europe • La compagnie Telelogic (maintenant IBM) a développé une suite d’outils appelée Tau • Inclut: • support pour l’utilisation de SDL et MSC • Pour voir si un scénario MSC est compatible avec une spec SDL • support pour l’implémentation (génération de code) • La compagnie PRAGMADEV a développé un outil semblable, Real Time Development Studio que nous pourrons voir dans des projets

  9. Brève intro à l’SDL (remerciements au prof. Alan Williams) L’SDL est essentiellement une notation graphique, même si une notation textuelle existe Il est une notation très riche, on pourrait lui dédier un cours entier! Deux éléments primaires: Structure Identifie les différentes composantes du système, et les voies de communication Composantes: Blocks, Processes Communication: Channels (entre blocs): communication qui prend du temps (mais on peut spécifier aussi nodelay) Signal routes (dans un bloc): communication instantanée Les points de connexion: Gates Tous les éléments structuraux peuvent être types, pour permettre l’orientation objet Behaviour - Comportement Seulement les processus ont un comportement Basé sur le modèle des machines à états finis étendues

  10. Structure à haut niveau: système, contient des blocks System SDLexample signaux en sortie [m2] Block_1 nom de canal toEnv2 toEnv1 [m3] signaux en entrée [m1] Block_2 path bloc [m4] Signaux permis dans ce canal canal environnement Les canaux sont des mileux de transm. avec files d’attente

  11. Déclarations de signaux(dans un système ou bloc ou processus) System SDLexample SIGNAL m1, m2, m3(INTEGER), m4, m5; paramètres Signaux sans paramètres

  12. Dans un Bloc (un système est composé de blocs, les blocs sont composés de processus) nom de bloc Block Block_1 sr1 SIGNAL m4, m5; Process_1 sr3 [m1] [m4] sr2 Process_2 signal route [m5] nom de signal route processus Signal routes livrent aux files d’entrée des processus

  13. Processus • À moins de spécification explicite, une instance d’un processus est créée à l’amorçage du système, et continuera jusqu’à ce que le processus décide de se terminer • Chaque processus reçoit (automatiquement par le système) son propre Process Identifier ou PID • Les processus peuvent être créés dynamiquement: No max d’instances P(1,3) P(0, ) No illimité d’instances No d’instances à l’initialisation

  14. Block Types System SDLexample2 [m1] Block_3: aType toEnv2 toEnv1 g2 [m1] g1 g2 Block_4:aType typeofinstance path g1 gatereferences [m4] [m4] aType block instances block type Un système qui consiste en deux Blocks ayant la même structure, décrite dans aType. Un gate est un point de connexion abstrait qui se reproduit dans toutes les instances d’un type

  15. Intérieur d’un Block Type block type name gate name Block Type aType g1 gate g1 [m4] sr4 [m4] [m4] Process_3 sr6 g2 g2 [m1] [m4] sr5 [m1] Process_4 gatereference [m5] Signaux permis à travers porte

  16. Détails • Les blocs peuvent contenir des sous-blocs ou aussi des processus • Les déclarations de signaux, listes de signaux, etc., peuvent être à tous les niveaux • Encourage la bonne pratique de faire les déclarations au niveau le plus interne • UML 2000 a introduit le concept d’agent, qui peut fonctionner comme un système, un block, un processus • Des agents peuvent inclure des agents

  17. Behaviour, Comportement • Seulement les processus peuvent avoir un comportement • Le comportement définit une machine à états finis étendue (EFSM) • Modèle: • Chaque processus a une (et seulement une) file d’entrée à travers laquelle il peut recevoir des signaux • Cette file est infinie théoriquement, mais finie en pratique • Signaux de sources différentes sont ajoutés à la même file à leur arrivée • Tandis que dans le modèle CFSM pur (Chap. 2) un proc a deux canaux pour chaque processus qui lui est connecté – un par direction • Quand un signal en tête d’une file d’entrée d’un processus est égal au signal d’entrée qui cause une transition d’état possible pour l’état courant du processus, cette transition est effectuée et le signal est enlevé de la file

  18. Communication entre processus en SDL … Chaque proc a sa propre file d’entrée, une seule P1 P3 P2 Un proc peut insérer des signaux dans sa propre file

  19. Communication dans modèle CFSM (Chap. 2) … … P1 P3 P2 Modèle CFSM ≠ Modèle SDL! Dans CFSM, un proc a une file d’entrée (et de sortie) pour chaque autre proc avec lequel il communique

  20. Transitions d’états en SDL • En principe, le modèle d’automate de SDL est le modèle Mealy: • Cependant ce modèle a été très élargi en SDL. • Les transitions peuvent être des programmes de complexité arbitraire entrée / sortie

  21. Transitions en SDL • Une transition contient une entrée au début • Sauf pour le cas de garde… (à voir) • Et peut contenir 0 ou plusieurs sorties • Même une boucle de sorties…

  22. SDL Behaviour – Comportement Observez les symboles pour les entrées, les sorties, et les états Process p1 état initial state1 état entrée m4 m2 state1 m5 m4 sortie state3 state2 prochain état

  23. Variables Type de variable: entier • Les déclarations sont séparées par des virgules, à la fin de toutes il y a un ; Nom de variable DCL v1 INTEGER, v2 PID, v3 BIT, v4 OCTET, v5 DURATION; Identificateur de proc 0 ou 1 huit bits Pour la minuterie

  24. Entrée de valeurs http://www.sdl-forum.org/sdl88tutorial/3/signals.htm

  25. Mécanismes d’interaction et transitions • Si à un moment donné la file d’entrée n’est pas vide, le premier signal en est enlevé • S’il y a une transition correspondante, elle est exécutée • Sinon le message est écarté, à moins que… (save!) • Observez différence par rapport au modèle CFSM • Dans CFSM, ceci serait une réception non-spécifiée

  26. SAVE Dans cet exemple, le signal reste dans le canal. Si p.ex. il a un C suivi par un A, * la transition A est effectuée, A est enlevé du canal * mais C reste dans le canal dans l’ordre d’arrivée. Il sera reproposé au prochain état (au lieu d’être écarté). save http://sdl-forum.org/sdl88tutorial/4/semantics_of_the_communication.htm

  27. Variables PID (v. Unix) • Chaque signal d’entrée porte automatiquement le PID du proc qui l’a envoyé • Chaque processus a une var prédéfinie SENDER • Quand un signal d’entrée est reçu, la value du PID de l’envoyeur est affecté à SENDER • Autres PIDs prédéfinis: • SELF: le PID de ce processus • PARENT: le processus qui a créé ce processus • OFFSPRING: le processus le plus récemment créé par ce processus • Les PIDs sont générés automatiquement par le système d’exécution, donc l’usager pourrait avoir quelque difficulté à les reconnaître…

  28. Minuterie • Actions avec minuterie • SET: Une minuterie est amorcée avec une valeur • Le langage ne spécifie pas les unités de temps • Les outils normalement utilisent les millisecondes • RESET: Annule une minuterie déjà amorcée • EXPIRY: Notification que la minuterie a expiré • Résultat: un message d’expiration avec un nom qui est celui de la minuterie est mis dans la file d’entrée du processus (!) • Ceci veut dire que une temporisation pourra être reçue quelque temps après

  29. Minuteries, timers set(now+5.0,t1) Amorce minuterie t1 Temporisation 5.0 “unités de temps” de maintenant state1 TIMER t1; t1 m2 Déclaration de t1 reset(t1) Rec. message d’expiration de t1 Annulation de minuterie

  30. SDL Process with Timers and Queues (O.Monkewich) Place timer signal into the queue Get signal from another process (queue always open) SET, RESET SDL Process Timer Send signal to process as soon as have one Input Queue (per process) Get value of NOW Send signal to another process Synchronize with global time Ask for value of NOW current time NB: diagramme utile, mais simplifié.

  31. Critique du concept de file en SDL • Les files premier-arrivé-premier servi en SDL fournissent un mécanisme fixe de communication entre blocs et processus • Dans la vie réelle, nous pouvons avoir plusieurs types de files: • Avec priorité, p.ex. messages peuvent se dépasser • Avec perte de messages • . . . • Ces différents types de files sont difficiles à exprimer en SDL, qui ne connaît qu’un seul type de file

  32. Programmer les transitions • Une transition, causée par une entrée du canal ou une garde, peut contenir un programme entier, impliquant 0 ou plusieurs sorties en positions différentes • Pour programmer ces transitions, plusieurs éléments sont fournis, correspondant aux bien connus organigrammes (flow-charts) état programme état

  33. Exemples d’éléments qui peuvent être utilisés dans une transition x := 0 Affectation de variables Prcd_name Appel de procédures Stop Prcs_name Création d’instance de processus

  34. Décisions dans transitions • Opérateurs: <, <=, >, >=, =, /= variable Condition logique true x = 3 x false = 1 =2 else conditions

  35. Gardes state1 DCL x INTEGER; m1 x < 0 Condition garde x = 5 m4 m3 state3 Si condition vraie on vient ici state2 Nous venons ici s’il n’y a pas d’entrée appropriée pour l’état et la cond est vraie La garde n’est pas nécess. reliée à la dernière entrée

  36. Fonctionnement des transitions avec gardes • On contrôle la file d’entrée • S’il y a un signal approprié dans la file d’entrée, on suit la transition pour ce signal • Si la file est vide ou il n’y a pas un signal attendu, mais la garde est vraie, on suit la transition de la garde

  37. États imbriqués, types d’états (diagramme par Rolv Braek) • En SDL 2000, un état peut contenir des autres états et même des processus entiers • Nous pouvons aussi avoir des ‘types’ d’états qui peuvent être instanciés

  38. Environnement L’environnement est connecté au système comme un autre processus L’environnement est supposé savoir quels messages envoyer à un moment donné, sinon ils seront écartés

  39. SDL/GR et SDL/PR http://www.sdl-forum.org/sdl2000present Erreur ici…

  40. Compilation, validation, test, etc • Le meilleurs outils SDL permettent de • Compiler du C++, ou Java… à partir de SDL • Valider l’SDL par rapport à des scénarios présentés comme MSC (voir après) • Générer des données de test qui peuvent être utilisées pour voir si une implantation correspond à la spec SDL • Outil TTCN à discuter plus tard

  41. Beaucoup de ressources dans le www • http://www.sdl-forum.org/ • http://www.sdl-forum.org/sdl88tutorial/ • http://www.sdl-forum.org/sdl2000present/ • http://www.sintef.no/time/elb40/html/elb/sdl/sdl_t01.htm • http://www.sintef.no/time/elb40/html/elb/sdl/sdl_t01.htm#30345 • www.cs.tut.fi/kurssit/TLT-9806/RolvBraekSDL.pdf Sources utilisées dans ce cours, merci! La norme officielle SDL est disponible: • http://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf

  42. Message Sequence Charts Figures prises de http://www.item.ntnu.no/fag/ttm4115/MSC_HTML-version/ Site utilisé Avec remerciements! Malheureusement ce site n’a pas été gardé à jour et quelques liens ne fonctionnent pas

  43. Introduction à MSC • Langage graphique et textuel pour spécifier les séquences d’événements dans un système • Semblables aux Diagrammes de séquence (sequence diagrams) de UML • Utilisé depuis longtemps en télématique, puis normalisé par l’ITU • Utilisé avec l’SDL, est la notation par laquelle les scénarios d’un système SDL sont présentés • Les outils SDL supportent la notation MSC • Normalisation amorcée en 1990, stable depuis 1996 • Notation aussi assez complexe • Deux parties: • MSC réguliers • montrent directement les messages possibles • MSC haut niveau (HLMSC) • montrent la corrélation entre MSC réguliers

  44. MSC notation de base 1: instances

  45. MSC Notation de base 2: messages

  46. MSC Notation de Base 3: conditions L’AC system fait ‘Card out’ avant d’envoyer l’OK, mais l’usager voit les deux événements dans l’ordre inverse

  47. Boucles et choix dans MSC boucle infinie choix Les boîtes arrondies sont des références à des MSC

  48. La sémantique est assez complexe • loop: nous pouvons avoir des conditions complexes d’itération • Exemple simple: loop <0,3> • alt: • Une seule des alternatives est exécutée • Normalement les alternatives ont des conditions de garde, et seulement les alternatives pour lesquelles la garde est vraie peuvent être exécutées

  49. High-Level MSC (HMSC) Un HLMSC est essentiellement une carte topographique qui combine plusieurs MSCs. Il ne montre pas de messages. La flèche veut dire que après la fin d’un MSC il y a l’autre condition Dans chaque boîte il y a un MSC

  50. Parallel merge dans HMSC par Cet HLMSC définit l’entrelacement des actions indiquées dans les deux MSC qu’il contient

More Related