La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Conception des protocoles de communication Azza Ouled Zaid Institut Supérieur dInformatique 2 ème année Cycle dIngénieurs.

Présentations similaires


Présentation au sujet: "1 Conception des protocoles de communication Azza Ouled Zaid Institut Supérieur dInformatique 2 ème année Cycle dIngénieurs."— Transcription de la présentation:

1 1 Conception des protocoles de communication Azza Ouled Zaid Institut Supérieur dInformatique 2 ème année Cycle dIngénieurs

2 2 Conception des protocoles Processus de conception des protocoles Spécification des protocoles Test des protocoles Spécification SDL

3 3 Techniques de conception Application des méthodes formelles et informatiques pour la conception des logiciels de communication Méthodes informelles : manque de fondation théorique définition ambiguë des dispositifs désirés pas moyen de vérifier la complétude et la consistance du système coût économique exorbitant Méthodes formelles : techniques mathématiques qui offrent une base rigoureuse du développement logiciel, qui mène à la justesse et la fiabilité à différentes étapes

4 4 Langage formel Une syntaxe formelle stricte exposer des énoncés de manière précise, concise et sans ambiguïté simplifier la manipulation et la transformation d'énoncés. Appliquer les règles de transformation précises développement de formules logiques, contrapositions, commutativité, associativité, etc. sans connaître la signification de l'énoncé transformé ou la signification de la transformation.

5 5 Langage formel Le seul langage permettant aux machines de « faire des mathématiques ». L'inconvénient : ne pas connaître le sens de l'énoncé empêche de savoir quelles sont les transformations pertinentes et nuit à l'intuition du raisonnement.

6 6 Méthodes formelles pour la conception des protocoles Offre une façon formelle et sûre pour la conception des protocoles modélisation des protocoles et spécification synthèse des protocoles Permet une analyse formelle avant limplémentation du protocole vérification et validation des protocoles analyse de performance des protocoles

7 7 Langage formel pour la conception des protocoles Une génération directe et automatique des programmes exécutables à partir dune spécification formelle Pas très répondu ni bien établi coût élevé en terme de temps et ressources apprendre un langage formel est aussi difficile quapprendre un langage de programmation

8 8 Principes de conception des protocoles Un concepteur adhère à une discipline si seulement si elle nous permet dobtenir : simplicité modularité faisabilité robustesse aux pannes comportement : ordonnancement, absence de blocage, cohérence des données partagées

9 9 Simplicité Un protocole bien structuré réalisé à partir dun petit nbre de blocs clairs et bien conçus Chaque bloc réalise convenablement une fonction Le fonctionnement des blocs et leur façon dinteragir. facile à comprendre et à implémenter, facile à vérifier et à maintenir. Les protocoles légers vérifient largument suivant : efficacité et vérifiabilité ne sont pas des objectifs orthogonaux mais complémentaires

10 10 Modularité Une hiérarchie des fonctions Une fonction complexe peut être construite avec des petits blocs qui interagissent dune manière simple. Chaque petit bloc est un protocole léger qui peut être séparément réalisé, vérifié, implémenté et maintenu Les fonctions orthogonales sont conçues dune façon indépendante. La structure du protocole résultant est ouverte, extensible, remplaçable sans affecter le fonctionnement des composants individuels

11 11 Modularité Une hiérarchie des fonctions Les modules individuels ne fixent aucune hypothèse sur la présence des autres modules ou leur fonctionnement. Le contrôle des erreurs et le contrôle des flots de données sont des fonctions orthogonales, résolus séparément Ils nimposent aucune hypothèse sur les données à part celui qui est strictement nécessaire à la réalisation de cette fonction Un système de correction ne doit pas imposer des hypothèses sur, codage des données, vitesse de transmission. Ces préoccupations, sils sont nécessaires sont placés dans dautres modules, spécialement optimisés à cet objectif

12 12 Protocole bien formé Ne doit pas contenir des codes inatteignables ou inexécutables. Complétude : un protocole incomplet peut causer des réceptions non définies durant lexécution. Borné : il ne dépasse pas les limites du système (capacité des files dattente). Stabilisation automatique : Si une erreur résiduelle change arbitrairement létat du protocole ce dernier retourne toujours à létat ciblé. Si le protocole est initialisé à partir dun état aléatoire il atteint létat ciblé dans un temps fini Adaptation dynamique Ex: adapter le débit de transmission à la capacité du canal et au débit de réception.

13 13 Robustesse Les événements inattendues exigent des considérations automatiques Pas difficile de concevoir un protocole qui travaille dans des conditions normales Leur défi est linattendu. le protocole doit être préparé pour traiter convenablement chaque action faisable et chaque chaîne daction réalisable sous nimporte quelle condition possible. Le protocole devrait prendre en charge au minimum son environnement pour éviter des dépendances sur les dispositifs particuliers qui pourraient changer.

14 14 Robustesse Une conception robuste est automatiquement mise à léchelle de la nouvelle technologie, sans exiger les changements fondamentaux. Une conception minimale qui élimine les contraintes non essentielles qui pourraient empêcher l'adaptation aux conditions imprévues. Élimination des aspects les moins pertinents pour ne considérer que ceux qui sont essentiels.

15 15 Cohérence Il y a quelques normes et manières redoutées dans lesquelles les protocoles peuvent échouer Blocage : états dans lesquels aucune autre exécution de protocole n'est possible, Ex: touts les processus du protocole attendent les conditions qui ne peuvent jamais être remplies. Boucle infinie : séquence dexécutions qui peuvent être répétées indéfiniment souvent sans accomplir jamais le progrès efficace. Arrêts non déterminé : l'accomplissement d'une exécution de protocole sans satisfaire les conditions darrêt appropriées.

16 16 En général, le respect de ces critères ne peut pas être vérifié par une révision manuelle des spécifications de protocole. Des outils plus puissants sont nécessaires pour les empêcher ou les détecter.

17 17 Les 5 éléments dun protocole Les spécifications de protocole se composent de cinq parties distinctes. Pour être complète, chaque spécification doit inclure explicitement : 1. Le service à fournir par le protocole 2. Les conditions au sujet de l'environnement dans lequel le protocole est exécuté 3. Le vocabulaire des messages employés pour mettre en application le protocole 4. Le codage (format) de chaque message dans le vocabulaire 5. Les règles de procédures gardant l'uniformité des échanges de message

18 18 Les 5 éléments dun protocole (suite) Létape 5, est le cœur dun protocole. Une assertion de justesse est une assertion sur la possibilité ou limpossibilité dun comportement Définir des formalismes pour décrire et vérifier le comportement des processus

19 19 Dix règles de base de conception de protocole 1. Assurez-vous que le problème est bien défini. 2. Définissez le service à réaliser à chaque niveau d'abstraction (qui vient avant et comment?). 3. Concevez la fonctionnalité externe avant la fonctionnalité interne. 4. Maintenez-la simplicité 5. Identifier les problèmes plus simples, les séparer, et puis les résoudre individuellement. 6. Ne reliez pas ce qui est indépendant. Séparez les préoccupations orthogonales.

20 20 Dix règles de base de conception de protocole (suite) 7. Ne présentez pas ce qui est négligeable. 8. Avant de mettre en application une conception, établissez un prototype à niveau élevé et vérifiez que les critères de conception sont rencontrés. 9. Implémenter la conception, mesurez sa performance, et au besoin, optimisez-la. 10. Vérifiez que la version finale dimplémentation optimisée est équivalente à la conception qui a été vérifiée. Ne sautez pas les règles 1 à 7. La règle 10 est la plus fréquemment violée

21 21 Développement des logiciels Le développement des logiciels passe par des phases qui amènent à la production dun système vérifiant certaines caractéristiques et répondant aux besoins préalablement requis. Ces phases font partie de tous les cycles de développement de systèmes indépendamment de : la nature, domaine, taille et la complexité du système à développer.

22 22 Le génie logiciel Le modèle du cycle de vie (ou de processus) dun logiciel est un modèle de phases qui commence quand le logiciel est conçu et se termine quand le produit nest plus disponible pour lutilisation. Plusieurs modèles de cycle de vie dun logiciel existent Le mode d'organisation le plus employé et normalisé par l'AFNOR (Association Française de Normalisation) est une technique par anticipation appelée Modèle en V

23 23 Le modèle de développement en V Le plus tôt quon identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger lerreur

24 24 Modèle dun logiciel Une spec formelle est un modèle abstrait Un modèle est une entité qui se comporte comme le système réel de certains points de vue P.ex. un modèle davion pourrait Être comme lavion, mais beaucoup plus petit Être comme lavion, mais ne pas voler Se comporter comme lavion pour le pilote, mais il ne peut pas avoir des passagers, ne peut pas voler, etc. (simulateur de vol) Donc il est une abstraction Un modèle formel dun logiciel est une entité mathématique qui a certaines des caractéristiques du logiciel, mais pas dautres P.ex. nest pas capable de fonctionner à la même vitesse, ne peut pas produire la sortie dans lexacte forme désirée, etc.

25 25 Différents niveaux de spécif et cycle de développement Nous pouvons effectuer des V&V et du test entre tous les niveaux Spec dexigences (langue naturelle, notation logique) Spécification du comportement Spécification de limplantation (comportement utilisant des composantes données) Implantation

26 26 Spécification dexigences ou besoins Ce que le système doit faire pour lusager, les exigences peuvent être à plusieurs niveaux dabstraction, peuvent représenter différents aspects du système Nombreuses méthodes de spec développés, p.ex. Use Cases (UML) Notations logiques Diagrammes de transitions détats…

27 27 Spécification du comportement Décrit le comportement du système en termes de séquences dinteractions possibles avec lenvironnement Les modèles à états sont les plus souvent utilisés, p.ex. au début, le système et dans létat inactif, ceci rend possible une transition signalisation, par laquelle le système passe à un état attente puis il passe à létat signal occupé La structure interne de la spec est abstraite, ne correspond pas à un modèle dimplantation

28 28 Spécification de limplantation Semblable à la spec du comportement Mais la spec a une structure interne qui correspond à un modèle dimplantation Décrit les composantes de limplantation, etc.

29 29 Vérification et test La vérification est une technique dont le rôle est de sassurer quun système corresponde aux exigences Une distinction plus fine est entre Validation: la fonctionnalité du système correspond-elle aux exigences de lusager? Vérification: le système, fonctionne-t-il bien? Dont lacronyme V&V Test: processus de détection de fautes par exécution et comparaison des résultats avec les exigences

30 30 Validation et vérification Conformité aux exigences : système |= spécification Validation : do we build the right product ? Vérification : do we build the product right ? En pratique : examen du code par une équipe indépendante test (en général ad hoc) Vérification en fin de conception irréaliste : il n'y a pas de spécification complète infaisable : outils de vérification pas assez puissants inutile : erreurs détectées trop tard intégrer V & V dans la conception

31 31 Techniques de vérification Vérification déductive règles de preuve associées aux instructions du programme vérification suivant la structure syntaxique mécanisation : assistants de preuve, démonstrateurs de théorèmes Vérification sémantique (model checking) méthode algorithmique de vérification exploration exhaustive de l'espace détats du modèle domaine d'application : hardware, protocoles de communication,. vérification de propriétés ou déquivalences entre modèles Pre-requis sémantique (opérationnelle ou axiomatique) des systèmes langage de spécification

32 32 Techniques de validation Simulation exécution d'un modèle du système prototypage, discussion avec le client Test appliquer des stimuli à l'implémentation du système Établir la conformité à l'objectif de test white box : structure interne du système connue black box : on ne connaît que l'interface du système montre la présence d'erreurs, jamais leur absence (Dijkstra) Standardisation : ISO-ITU-T 96 génération de cas de test (use case) pour l'objectif visé sélection d'un sous-ensemble représentatif implantation des cas de test exécution avec le logiciel test analyse des résultats

33 33 Cycle de vie du système de télécommunication Étude préalable de besoin Spécification Conception générale Implémentation : Spécification logicielle Conception préliminaire Conception détaillée et Génération du code Tests d'intégration (cible) Déboguage Tests unitaires Tests d'intégration (hôte) Tests fonctionnels Exploitation maintenance

34 34 Spécifications des protocoles Les spécifications de protocole consiste à préciser lensemble des objectifs à réaliser par la mise en œuvre pratique définir le comportement requis pour une entité de protocole

35 35 Spécifications des protocoles la nature des spécifications de protocole a une influence forte sur le test du protocole test de conformité : moyen dassurer la satisfaction de limplémentation du protocole aux besoins Les systèmes de protocole ne sont pas des systèmes logiciels traditionnels, mais une variante du logiciel Les systèmes traditionnels se composent des fonctions qui partent d'un état initial vers un état final ces systèmes s'appellent transformationnels parce qu'ils transforment un premier état à un état final les exemples typiques : fabrication, traitements des données différés, progiciels Progiciel :Logiciel d'application paramétrable, destiné à la réalisation de diverses tâches.

36 36 Spécifications des protocoles Les systèmes réactifs peuvent ne jamais se terminer le but d'exploiter les systèmes réactifs est de maintenir l'interaction avec l'environnement système un système réactif ne peut pas être spécifier en se référant seulement à ses états initiaux et finals, mais plutôt à son comportement continu les exemples typiques sont les logiciels d'exploitation, les systèmes de contrôle de processus, et les systèmes de protocole de communication

37 37 Spécifications des protocoles Système de protocole de communication = système réactifs Techniques de description formelles : réseaux de Pétri, grammaires formelles, langages de programmation à haut niveau, algèbres de processus, types de données abstraits, et logique temporelle, Les Machine à État fini (MEF) ont été souvent étendues par l'addition des paramètres et des attributs de données afin de traiter naturellement certaines propriétés des protocoles par exemple numérotation des séquences et adressage

38 38 Introduction à SDL SDL : Specification and Description Language

39 39 Développement Au début SDL nétait quun simple formalisme graphique pour spécifier les machines à états finis des protocoles téléphoniques 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 lorientation objet En 1996 on ajouta ASN.1, une notation pour la spec des structures de données et les Message Sequence Charts Aujourdhui SDL et MSC sont deux notations intégrées Nous avons couramment un effort dintégration de SDL dans UML

40 40 Brève intro à lSDL LSDL est essentiellement graphique, même si une notation textuelle existe 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 Signal routes (dans un bloc): communication instantanée Les points de connexion: Gates Behaviour - Comportement Seulement les processus ont un comportement Basé sur le modèle des machines à états finis étendues

41 41 Structure à haut niveau Block_1 Block_2 Example de system SDL canal environnement path toEnv1 toEnv2 [m2] [m3] [m1] [m4] bloc nom de canal signaux en sortie signaux en entrée Signaux permis dans ce canal

42 42 Déclarations de signaux (dans un système ou bloc ou processus) SIGNAL m1, m2, m3(INTEGER), m4, m5; paramètres

43 43 Dans un Bloc un système est composé de blocs, les blocs sont composés de processus Block Block_1 nom de bloc Process_1 Process_2 [m1] [m4] [m5] signal route processus sr1 sr2 sr3 nom de signal route SIGNAL m5;

44 44 Processus À moins de spécification explicite, une instance dun processus est créée à lamorç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: P(1,3) No dinstances à linitialisation P(0, ) No max dinstances No illimité dinstances

45 45 Block_3: aType Block_4: aType Example2 Block Types path toEnv1 toEnv2 [m1] [m4] g1 g2 g1 g2 aType block type block instances type of instance gate references

46 46 Intérieur dun Block Type Block Type aType block type name Process_3 Process_4 [m4] [m1] [m5] gate reference gate sr4 sr5 sr6 gate name g1 g2 [m4] [m1] [m4] Signaux permis à travers porte g2 [m4] g1

47 47 Process Types P_type Symbol: P1: P_type Instance:

48 48 Signal List pour abréger les listes SIGNAL m1, m2, m3(INTEGER), m4; SIGNALLIST list1 m1, m2, m3, m4; Example3 signal list name Block_b [(list1)] Utilisation de signal list

49 49 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

50 50 Behaviour, Comportement Seulement les processus peuvent avoir un comportement Le comportement définit une machine à états finis étendue (MEFE) Modèle: Chaque processus a une (et seulement une) file dentré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 MEFC (Chap. 4) il y a un canal pour chaque paire de processus communicants Quand un signal en tête dune file dentrée dun processus est égal au signal dentré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

51 51 Communication entre processus P1 P2 P3 … Chaque proc a sa propre file dentrée, une seule Un proc peut insérer des signaux dans sa propre file

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

53 53 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…

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

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

56 56 Entrée de valeurs

57 57 Mécanismes dinteraction et transitions Si à un moment donné la file dentrée nest pas vide, le premier signal est enlevé Sil y a une transition correspondante, elle est exécutée Sinon le message est écarté, à moins que… (save!)

58 58 SAVE Dans cet exemple, le signal C est remis dans le canal. Si p.ex. il y a un signal A après le C, la transition A est effectuée mais C reste dans le canal. Malheureusement, la manière dans laquelle cette fonctionnalité est censée fonctionner nest pas définie dans la norme et elle est laissée à limplémentation Questions possibles, pas résolues dans la norme : Dans quelle position du canal est-il mis? Au début ou à la fin? Sera-t-il encore disponible si le prochain état aussi ne peu pas lutiliser? save

59 59 Variables PID Chaque signal dentrée porte automatiquement le PID du proc qui la envoyé Chaque processus a une var prédéfinie SENDER Quand un signal dentrée est reçu, la valeur du PID de lenvoyeur 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 dexécution, donc lusager pourrait avoir quelques difficultés à les reconnaître…

60 60 Gardes state1 m3 state2 m4 m1 state3 x = 5 x < 0 Nous venons ici sil ny a pas dentrée appropriée pour létat et la cond est vraie DCL x INTEGER; Condition garde Si condition vraie on vient ici

61 61 Fonctionnement des transitions avec gardes On contrôle la file dentrée Sil y a un signal approprié dans la file dentrée, on suit la transition pour ce signal Si la file est vide ou il ny a pas de signal attendu, mais la garde est vraie, on suit la transition de la garde

62 62 Minuterie Actions avec minuterie SET: Une minuterie est amorcée avec une valeur Le langage ne spécifie pas les unités de temps Défaut outil Tau: millisecondes RESET: Annule une minuterie déjà amorcée EXPIRY: Notification que la minuterie est déclenchée Résultat: un message dexpiration avec un nom qui est celui de la minuterie est mis dans la file dentrée du processus (!) Ceci veut dire que une temporisation pourra être reçue quelque temps après

63 63 Minuteries, timers set(now+5.0,t1) Amorce minuterie t1 Temporisation 5.0 unités de temps de maintenant state1 t1m2 reset(t1) TIMER t1; Rec. message dexpiration de t1 Annulation de minuterie Déclaration de t1

64 64 SDL Process with Timers and Queues SDL Process Input Queue (per process) Timer Synchronize with global time Get value of NOW Ask for value of NOW Send signal to another process Get signal from another process (queue always open) Place timer signal into the queue Remove timer signal from the queue Timer signal consumed by SDL process (can deactivate) SET, RESET Ready to consume a signal Send signal to process as soon as have one Modified FIFO RESET – remove from queue and de-activate (stop counting) SET – RESET and activate (start counting) 3 states of a timer - active - inactive - timer signal in queue current time

65 65 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)

66 66 Exemples déléments qui peuvent être utilisés dans une transition x := 0 Affectation de variables Prcd_name Appel de procédures Prcs_name Création dinstance de processus Terminaison de processus

67 67 Décisions Opérateurs:, >=, =, /= x = 3 true false x =2 = 1 else variable conditions Condition logique

68 68 Entrée/sortie de signaux Options pour les sorties des signaux: Le signal est envoyé sur la route spécifiée Le signal est envoyé au processus spécifié m3 VIA signal_route_name m3 TO process_id

69 69 Environnement Lenvironnement est connecté au système comme un autre processus Lenvironnement est supposé savoir quels messages à envoyer à un moment donné, sinon ils seront écartés

70 70 SDL/GR et SDL/PR

71 71 Message Sequence Charts

72 72 Introduction à MSC Langage graphique et textuel pour spécifier les séquences dévénements dans un système semblable aux Diagrammes de séquence de lUML La notation par laquelle les scénarios dun système SDL sont présentés Deux parties: MSC réguliers montrent directement les messages possibles MSC haut niveau (HLMSC) montrent la corrélation entre MSC réguliers

73 73 Diagrammes de séquences (Message Sequence Charts MSC) Décrivent les protocoles de manière visuelle communications et interactions Expriment des scénarios positifs/négatifs entre processus concurrents. Utilisés au début du cycle de développement abstraction des données, etc... Standard de la norme Z.120 de l'ITU (CCITT), utilisés dans UML (Unified Modeling Language). La visualisation de la trace du message est choisi dune manière simple et intuitive

74 74 Diagrammes de séquences (Message Sequence Charts MSC) Pour la spécification du transfert des fichiers Frontières des interfaces, commande séquentielle des messages, temporisateurs etc... Chaque diagramme MSC représente un scénario d'un échange typique ou exceptionnel des messages entre les entités du système

75 75 MSC for B-ISDN (outgoing call)

76 76 Message Sequence Graphs (MSG) Un MSG est un graphe, dont les noeuds sont étiquetés par des MSC. Le MSG décrit une spécification comme un ensemble (éventuellement infini) de MSC, correspondant aux chemins acceptants du graphe. Lors des branchements, les choix locaux des processus doivent respecter le contrôle global donné par l'étiquette d'un noeud.

77 77 Exemple MSG

78 78 Exemple (MSC)

79 79 SDL : Specification and Description Language MSC et SDL décrivent le même comportement avec deux perspectives différentes SDL montre comment se comporte chaque entité communicante, alors que les diagrammes MSC montrent comment ils interagissent l'un sur l'autre en échangeant des messages Avec des spécifications des systèmes de communication complexes Structure (architecture) des systèmes faire coopérer des parties ( systèmes, blocs, processus) Communications avec l'environnement et dans le système Canaux comme chemins de communications Signaux comme les messages transférés à travers le canal Comportement dynamique de chaque pièce basé sur des machines d'état

80 80 Annexes

81 81 Annexes

82 82 Annexes

83 83 Annexes


Télécharger ppt "1 Conception des protocoles de communication Azza Ouled Zaid Institut Supérieur dInformatique 2 ème année Cycle dIngénieurs."

Présentations similaires


Annonces Google