Conception des protocoles de communication

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 • Conception des protocoles • Processus de conception des protocoles • Spécification des protocoles • Test des protocoles • Spécification SDL

3. 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 Techniques de conception

4. 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. Langage formel

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. 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 Méthodes formelles pour la conception 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. 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 Principes de conception des protocoles

9. 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 Simplicité

10. 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 Modularité — Une hiérarchie des fonctions

11. 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 Modularité — Une hiérarchie des fonctions

12. 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. Protocole bien formé

13. 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. Robustesse

14. 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. Robustesse

15. 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. Cohérence

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. 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. Dix règles de base de conception de protocole

20. 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 Dix règles de base de conception de protocole (suite)

21. 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. Développement des logiciels

22. 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 Le génie logiciel

23. Le plus tôt qu’on identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger l’erreur Le modèle de développement en V

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. Spec d’exigences (langue naturelle, notation logique) Spécification du comportement Spécification de l’implantation (comportement utilisant des composantes données) Implantation Différents niveaux de spécifet cycle de développement • 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. Exploitation maintenance Spécification Tests fonctionnels Conception générale Tests d'intégration (cible) • Implémentation : • Spécification logicielle • Conception préliminaire • Conception détaillée et • Génération du code Déboguage Tests unitaires Tests d'intégration (hôte) Cycle de vie du système de télécommunication É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. 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 Block_4:aType typeofinstance path g1 gatereferences [m4] [m4] aType block instances block type

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

47. Process Types P_type Symbol: 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 designal 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