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

Conception des protocoles de communication

Présentations similaires


Présentation au sujet: "Conception des protocoles de communication"— Transcription de la présentation:

1 Conception des protocoles de communication
Azza Ouled Zaid Institut Supérieur d’Informatique 2ème année Cycle d’Ingénieurs

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

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 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 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 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 l’implémentation du protocole vérification et validation des protocoles analyse de performance des protocoles

7 Langage formel pour la conception des protocoles
Une génération directe et automatique des programmes exécutables à partir d’une 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 qu’apprendre un langage de programmation

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

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

10 Modularité — Une hiérarchie des fonctions
Une fonction complexe peut être construite avec des petits blocs qui interagissent d’une 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 d’une façon indépendante. La structure du protocole résultant est ouverte, extensible, remplaçable sans affecter le fonctionnement des composants individuels

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 n’imposent 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, s’ils sont nécessaires sont placés dans d’autres modules, spécialement optimisés à cet objectif

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 l’exécution. Borné : il ne dépasse pas les limites du système (capacité des files d’attente). 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 d’un é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 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 l’inattendu. le protocole doit être préparé pour traiter convenablement chaque action faisable et chaque chaîne d’action réalisable sous n’importe 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 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 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 d’exé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 d’arrêt appropriées.

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 Les 5 éléments d’un protocole
Les spécifications de protocole se composent de cinq parties distinctes. Pour être complète, chaque spécification doit inclure explicitement : Le service à fournir par le protocole Les conditions au sujet de l'environnement dans lequel le protocole est exécuté Le vocabulaire des messages employés pour mettre en application le protocole Le codage (format) de chaque message dans le vocabulaire Les règles de procédures gardant l'uniformité des échanges de message

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

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

20 Dix règles de base de conception de protocole (suite)
Ne présentez pas ce qui est négligeable. Avant de mettre en application une conception, établissez un prototype à niveau élevé et vérifiez que les critères de conception sont rencontrés. Implémenter la conception, mesurez sa performance, et au besoin, optimisez-la. Vérifiez que la version finale d‘implé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 Développement des logiciels
Le développement des logiciels passe par des phases qui amènent à la production d’un 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 Le génie logiciel Le modèle du cycle de vie (ou de processus) d’un logiciel est un modèle de phases qui commence quand le logiciel est conçu et se termine quand le produit n’est plus disponible pour l’utilisation. Plusieurs modèles de cycle de vie d’un 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 Le modèle de développement en V
Le plus tôt qu’on identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger l’erreur

24 Modèle d’un 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 d’avion pourrait Être comme l’avion, mais beaucoup plus petit Être comme l’avion, mais ne pas voler Se comporter comme l’avion 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 d’un logiciel est une entité mathématique qui a certaines des caractéristiques du logiciel, mais pas d’autres P.ex. n’est pas capable de fonctionner à la même vitesse, ne peut pas produire la sortie dans l’exacte forme désirée, etc.

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

26 Spécification d’exigences ou besoins
Ce que le système doit faire pour l’usager, les exigences peuvent être à plusieurs niveaux d’abstraction, 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 Spécification du comportement
Décrit le comportement du système en termes de séquences d’interactions possibles avec l’environnement 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 d’implantation

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

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

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 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 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 Cycle de vie du système de télécommunication
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) fonctionnels Exploitation maintenance Étude préalable de besoin

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

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 d’assurer la satisfaction de l’implé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 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 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 SDL : Specification and Description Language
Introduction à SDL SDL : Specification and Description Language

39 Développement Au début SDL n’était qu’un 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 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 Nous avons couramment un effort d’intégration de SDL dans UML

40 Brève intro à l’SDL L’SDL 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 Structure à haut niveau
Example de system SDL 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

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

43 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 m5; Process_1 sr3 [m1] [m4] sr2 Process_2 signal route [m5] nom de signal route processus

44 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

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

46 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 gate reference [m5] Signaux permis à travers porte

47 Process Types Symbol: P_type P1: P_type Instance:

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

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 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 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 MEFC (Chap. 4) il y a un canal pour chaque paire de processus communicants 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

51 Communication entre processus
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

52 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é élargi en SDL. Les transitions peuvent être des programmes de complexité arbitraire entrée / sortie

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 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 m5 m4 state1 sortie state2 state3 prochain état

55 Variables DCL v1 INTEGER, v2 PID, v3 BIT, v4 OCTET, v5 DURATION;
Type de variable: entier 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 Les déclarations sont séparées par des virgules, à la fin de toutes il y a un ;

56 Entrée de valeurs

57 Mécanismes d’interaction et transitions
Si à un moment donné la file d’entrée n’est pas vide, le premier signal est enlevé S’il y a une transition correspondante, elle est exécutée Sinon le message est écarté, à moins que… (save!)

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 n’est pas définie dans la norme et elle est laissée à l’implé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 l’utiliser? save

59 Variables PID 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 valeur 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 quelques difficultés à les reconnaître…

60 Gardes state1 DCL x INTEGER; m1 x < 0 x = 5 m4 m3 state3 state2
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

61 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 de signal attendu, mais la garde est vraie, on suit la transition de la garde

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

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

64 SDL Process with Timers and Queues
Place timer signal into the queue Get signal from another process (queue always open) Remove timer signal from the queue Timer signal consumed by SDL process (can deactivate) Modified FIFO SET, RESET Ready to consume a signal Timer SDL Process 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 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 Ask for value of NOW current time

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 Exemples d’éléments qui peuvent être utilisés dans une transition
Affectation de variables Prcd_name Appel de procédures Terminaison de processus Prcs_name Création d’instance de processus

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

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

70 SDL/GR et SDL/PR http://www.sdl-forum.org/sdl2000present

71 Message Sequence Charts

72 Introduction à MSC MSC réguliers MSC haut niveau (HLMSC)
Langage graphique et textuel pour spécifier les séquences d’événements dans un système semblable aux Diagrammes de séquence de l’UML La notation par laquelle les scénarios d’un 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 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 d’une manière simple et intuitive

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 MSC for B-ISDN (outgoing call)

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 Exemple MSG

78 Exemple (MSC)

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 Annexes

81 Annexes

82 Annexes

83 Annexes


Télécharger ppt "Conception des protocoles de communication"

Présentations similaires


Annonces Google