Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

1 Ingénierie des protocoles de communication Haykal Tej Inst. Sup. d’Informatiq

1 Ingénierie des protocoles de communication Haykal Tej Inst. Sup. d’Informatique et des Technologies de Communication, Hammam Sousse Université de Sousse htej@gmx.de 2 Chapitre 1 Généralités sur les protocoles et les méthodes de génie de protocoles Préambule Un protocole est un ensemble de règles qui gouvernent l'interaction entre processus parallèles dans les systèmes distribués La conception de protocoles n'est pas une discipline à part, elle est liée à la fois aux réseaux et à l'ingénierie des systèmes Décrire complètement et sans ambiguïté un protocole est difficile Prouver qu'un protocole est correct est une tâche encore plus ardue => Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de montrer comment on peut (bien) les décrire Protocoles de communication… Autopsie d'un accident… Accident du tunnel de Clayton, 1861  un train peut entrer dans le tunnel si le sémaphore est vert  en passant le sémaphore, le train le met au rouge automatiquement ; en cas de défaillance du système, c'est l'opérateur qui agite un drapeau rouge  c'est l'opérateur qui remet le sémaphore au vert quand il est sur que le train a quitter le tunnel  deux télégraphes permettent aux opérateurs de s'échanger quelques messages  « Train in tunnel »  « Tunnel is clear »  Pour plus de sécurité, un 3è message est prévu : "Has the train left the tunnel?" A B Autopsie d'un accident… Accident du tunnel de Clayton, 1861 : ce qui s'est passé  Un train passe le sémaphore A (vert), mais le sémaphore ne passe pas au rouge.  L'opérateur réagit : il envoie le message "Train in tunnel" et agite un drapeau rouge pour arrêter les trains suivants.  Cependant, un 2è train est arrivé trop vite et est passé au vert.  Heureusement, le conducteur a entrevu le drapeau rouge in extremis.  Un 3è train arrive et s'arrête  L'opérateur envoie à nouveau le signal "Train in tunnel" pour avertir l'autre qu'il y a 2 trains dans le tunnel.  Le protocole n'a pas prévu ce cas.  Le problème pour l'opérateur A est maintenant de savoir quand les deux trains ont quitté le tunnel afin d'autoriser le 3è à entrer.  Pour alerter son collègue, l'opérateur A envoie le signal "Has the train left the tunnel?"  Lorsque le premier train sort du tunnel, l'opérateur B répond "Tunnel is clear"  Ne sachant pas si les 2 trains ont quitté le tunnel, l'opérateur A attend un certain temps, puis autorise le 3è train à entrer.  Malheureusement, le conducteur du 2è train, qui avait vu le drapeau, s'était arrêté dans le tunnel. Après un certain temps de réflexion, il a même fait marche arrière… => 23 morts et 176 blessés Autopsie d'un accident… Accident du tunnel de Clayton, 1861 : conclusion Il est difficile d'établir la responsabilité de cet accident. A partir du moment où le 2è train est entré dans le tunnel, il n'y avait plus moyen de récupérer la situation. L'ensemble des messages disponibles sur les télégraphes était incomplet. Le bon sens des opérateurs n'était pas suffisant. La réaction est toujours la même : I could not imagine that could ever happen Au début, beaucoup d'accidents étaient dus au manque de moyens de communication, mais on a constaté ensuite qu'il était surtout très difficile d'établir des règles non ambiguës de communication. Structure d'un protocole… Pour définir un protocole, nous devons définir un ensemble de règles : définir comment un message est encodé comment une transmission est démarrée et terminée, etc Deux types d'erreurs sont difficiles à éviter : la conception d'un ensemble incomplet de règles (incomplétude) la conception de règles contradictoires (inconsistance) Cela requiert : de définir tous les éléments essentiels du protocole une discipline pour les définir en séparant les éléments indépendants La vraie difficulté vient du parallélisme. Le nombre de scénarios est en général énorme et difficile à appréhender Historique… « Le génie logiciel, en tant que discipline informatique, est né en octobre 1968 lors d’une conférence de l’OTAN à Garmisch- Partenkirchen pour répondre à un problème qui devenait de plus en plus évident : d’une part le logiciel n’est pas fiable, d’autre part il est incroyablement difficile de réaliser dans les délais prévus des logiciels satisfaisant leur cahier des charges » discipline de l’ingénieur du logiciel, pour l’aider développer des systèmes informatiques fiables, i.e., satisfaisant leur cahier des charges, dans des délais raisonnables « génie logiciel » comme génie chimique, génie électrique, génie mécanique… = ensemble des techniques, outils et méthodes visant à optimiser et rationaliser la production du logiciel et son suivi 1.1. Pourquoi l'ingénierie des logiciels Example: auto-pilot Problem: “Design a part in auto-pilot that avoids collision with other planes.” Solution: “When distance is 1km, give warning to other plane and notify pilot. When distance is 300m, and no changes in the course of other plane were noticed, go up to avoid collision” Problem with solution Both planes have the same software. Both go up... This happens in real software! Some famous bugs NASA Space Rover, Intel floating point processor, etc. Hard to predict all behaviours! US aircraft went to southern hemisphere and … flipped when crossing the equator Air traffic controller: US to Britain.  It never dealt with problem of 0 degrees longitude. Result: software “folded” Britain along Greenwich Meridian Software written for US F-16 accidents when reused in Israeli aircraft flown over the Dear Sea (altitude < sea level) Year 2000 problem Yet more such examples NASA Space Shuttle software (in use since 1980) 16 severity-level 1 software errors 8 remained in code that was used in flights none encountered during flights total size - only 400,000 words Remarque : les méthodes et techniques issues du génie logiciel sont imposées par les autorités de certification pour le développement de systèmes critiques (avionique, nucléaire…) normes de développement de systèmes (DO178B…) => Pour continuer, quelques exemples de systèmes complexes… 1.1. Pourquoi l'ingénierie des logiciels Exemples : Le Système de Navigation et d'Attaque d'un Rafale = 2 millions de lignes de codes ADA 50 équipements (numériques ou analogiques), 12 calculateurs Contraintes de temps < 1ms … combinatoire des modes et des états élevée Landing System : plus de 1014 états possibles Side Displays Management : plus de 2.108 états possibles 1/2 million d’instructions pour une expérience de physique des particules 1 million d’instructions dans un central téléphonique 50 millions d’instructions dans la navette spatiale Nécessité de rigueur dans la conception 1.1. Pourquoi l'ingénierie des logiciels Si l'on veut maîtriser le développement de systèmes à logiciels fiables, il faut : rédiger de façon claire les spécifications du système (ce que l'on attend) => comment être sûrs que ces spécifications sont complètes ? => comment être sûrs que ces spécification sont cohérentes ? valider/vérifier toutes les étapes du développements => a-t-on des moyens de validation/vérification (mathématiques)? de réutiliser des sous-systèmes déjà réalisés (mais pas n'importe comment) => a-t-on des règles, des outils pour aider à la réutilisation ? nécessité d’une base théorique et d’une approche ingénierie (science de l’ingénieur) du logiciel 1.1. Pourquoi l'ingénierie des logiciels Pour maximiser la qualité d'un système il faut... Introduction d'un cycle de vie : identifier un ensemble d'étape importante dans le développement, et des documents importants… analyse de besoins, spécification, conception, programmation, intégration… ranger ses étapes dans le temps et les unes par rapport aux autres => cycles en cascade, en V, en Y, en spirale… 1.2. Eléments de terminologie Pourquoi des techniques formelles… Techniques formelles : reposent sur des fondements mathématiques expression mathématique des objets du développement (le comportement des systèmes) expression mathématique des propriétés expression mathématique des preuves permettent l'analyse (mathématique) du comportement d'un système Remarque : certains organismes imposent déjà l'utilisation de techniques mathématiques dans le développement de systèmes informatiques : dans le domaine de la sécurité : obligation d'utiliser des méthodes formelles pour certains niveaux de sécurité dans le ferroviaire… (métro Météor) Qu'apportent les techniques formelles ? Les bases mathématiques (logique, théorie des ensembles…) d’une technique formelle fournissent les notions de consistance, cohérence à partir d'une spécification S, on ne peut pas déduire "a" et "non a" Qu'est-ce qu'une technique formelle… Programme Spécification globale Besoins des utilisateurs Architecture et spécification des composants activité de spécification Axe du développement vérification de consistance Une autre spécification globale vérification d'équivalence Qu'apportent les techniques formelles ? Les bases mathématiques (logique, théorie des ensembles…) d’une technique formelle fournissent les notions de correction d'une implémentation par rapport à une spécification il est possible de décider si un programme P implémente une spécification S Qu'est-ce qu'une technique formelle… Programme Spécification globale Besoins des utilisateurs Architecture et spécification des composants activité de spécification activité de conception activité de programmation vérification vérification Axe du développement Que n'apportent pas les techniques formelles ? La démonstration de la validité de la spécification globale par rapport aux besoins de l'utilisateur est impossible => parce que les besoins de l'utilisateurs ne sont pas exprimés en termes mathématiques ! Qu'est-ce qu'une technique formelle… Programme Spécification globale Besoins des utilisateurs Architecture et spécification des composants uploads/Voyage/ ingenierie-des-protocoles-chap01.pdf