1 / 93

Chapitre 1

Chapitre 1. Généralités sur les protocoles et les méthodes de génie de protocoles. w3.uqo.ca/luigi. Ce chapitre…. Cycle de développement des protocoles V&V, test Modèles à couches Modèles OSI Connexion ou non Un peu d’histoire Le monde de la normalisation. Sujet du cours. Méthodes de:

carly-walls
Download Presentation

Chapitre 1

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 1 Généralités sur les protocoles et les méthodes de génie de protocoles w3.uqo.ca/luigi

  2. Ce chapitre… • Cycle de développement des protocoles • V&V, test • Modèles à couches • Modèles OSI • Connexion ou non • Un peu d’histoire • Le monde de la normalisation INF6001 Chap 1

  3. Sujet du cours • Méthodes de: • Spécification • Conception • Validation • Vérification • Test • De protocoles de communication INF6001 Chap 1

  4. Vérification, validation (V&V) et test • La V&V est une technique pour s’assurer qu’un système corresponde à ses exigences • Une distinction subtile est souvent faite entre • Validation: la fonctionnalité du système correspond-elle aux exigences de l’usager (requirements) • Vérification: le système, fonctionne-t-il bien? • Dont l’acronyme V&V • Cependant nous n’utiliseront pas beaucoup cette distinction • Test: processus de détection de fautes par exécution sur des cas choisis et comparaison des résultats avec les exigences INF6001 Chap 1

  5. Spécifications et exigences • Les mots spécification et exigences sont utilisés dans plusieurs significations INF6001 Chap 1

  6. Différents niveaux de spécifet 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 INF6001 Chap 1

  7. Loi dans le génie logiciel • Le plus tôt qu’on identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger l’erreur INF6001 Chap 1

  8. Spécification d’exigences ou besoins • Ce que le système doit faire pour l’usager, p.ex pour un système téléphonique: (niveaux d’abstraction décroissants) • Me permettre de communiquer avec l’appelé si disponible • Après avoir signalé un numéro, il doit sonner de l’autre côté ou sinon l’appelant doit recevoir un signal occupé • Être au début en état inactif, donner la tonalité au décrochage et passer à un état où il permet de composer un numéro… • Donc les exigences peuvent être à plusieurs niveaux d’abstraction, peuvent représenter différents aspects du système • Il y a tout un domaine de recherches qui s’appelle • Requirement Engineering • Nombreuses méthodes de spec développés, p.ex. • Use Cases (UML) • Use Case Maps • Notations logiques (OCL en UML) • Diagrammes de transitions d’états… Spec d’exigences (langue naturelle, notation logique) Spécification du comportement Spécification de l’implantation (comportement utilisant des composantes données) INF6001 Chap 1 Implantation

  9. 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, idle • ceci rend possible une transition signalisation, par laquelle le système passe à un état attente • il passe puis à l’état sonnerie ou signal occupé • La structure interne de la spec est abstraite, ne correspond pas nécessairement à un modèle d’implantation Spec d’exigences (langue naturelle, notation logique) Spécification du comportement Spécification de l’implantation (comportement utilisant des composantes données) INF6001 Chap 1 9 Implantation

  10. Spec partielle du comportement d’un téléph. CallAlert StartRinging Idle OffHook DialTone Dialing Ringing OnHook Click DialDIgits Clicks OffHook StopRing Path Active Mess. entrée Mess. sortie Notation: INF6001 Chap 1

  11. Spécification de l’implantation • Semblable à la spec du comportement • Mais la spec a une structure interne qui correspond à un modèle d’implantation • P.ex. un diagramme à état pour chaque composante • Décrit les composantes de l’implantation, etc. INF6001 Chap 1

  12. Vérification ou test entre niveaux • Il est nécessaire de contrôler tous les suivants, et ces contrôles peuvent être faits par V&V ou test: • Que la spec du comportement inclut tout le comportement décrit dans les exigences • Possiblement aussi qu’il n’y a pas de comportements additionnels indésirables • Que la spec de l’implantation inclut tout le comportement décrit dans la spec du comportement et, au besoin, dans la spec des exigences • Que l’implantation inclut tout le comportement décrit dans la spec des exigences et au besoin dans la spec du comportement • Le besoin de tous ces contrôles est réduit si les différentes niveaux de specs et d’implantation sont obtenus les uns des autres à l’aide d’outils automatiques ou semi-automatiques • p.ex. compilation INF6001 Chap 1

  13. Placement de la vérification et test • Dans la plupart des modèles de développement du logiciel, la vérification et surtout le test sont considérés comme étapes finales du processus • Elles devraient au lieu être considérées comme activités parallèles à être exécutées à toutes les étapes • Pour contrôler la cohérence entre étapes et la complétude de chaque étape INF6001 Chap 1

  14. Spécifications formelles • Afin de rendre la V&V et le test plus précis et fiables, le concept de spécification formelle a été développé • Une spécification formelle d’un système est une spécification du comportement désiré du système, écrite dans une notation fournie d’une base logique, • Donc adaptable à des processus de vérification et tests automatisés • Une spec formelle peut être prise comme expression d’exigences d’usager • Ou une spec formelle peut elle-même être testées ou validée, vérifiée par rapport à des exigences exprimées d’une autre façon (langue naturelle, autre langage formel) • Aussi, les specs formelles peuvent être utilisées comme terme de comparaison pour la V&V ou le test • À voir… c’est le contenu de ce cours INF6001 Chap 1

  15. Modélisation de systèmes informatiques • Dans leur réalité physique, les systèmes informatiques sont extrêmement complexes • Courants électriques qui circulent dans un système • Peuvent être interprétées de façons différentes • Afin de les analyser, il est nécessaire d’utiliser des simplifications, des abstractions, des interprétations: • Chercher à capturer ce que l’usager peut considérer important à un moment donné • Toute simplification, tout modèle • Capture certaines propriétés et en ignore autres • Capture certaines possibilités d’erreur et en ignore d’autres • P.ex. dans ce cours nous ne prendrons pas en considération les aspects temps réel INF6001 Chap 1

  16. Modèle • 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 toutes • 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. INF6001 Chap 1

  17. Conception et description à couches INF6001 Chap 1

  18. Couches dans logiciels Couche n+1 Utilise les services de la couche n et fournit des services à la couche n+2 Couche n Utilise les services de la couche n-1 et fournit des services à la couche n+1 Couche n-1 Utilise les services de la couche n-2 et fournit des services à la couche n Services = fonctionnalités En pratique, les services seront des méthodes ou fonctions INF6001 Chap 1

  19. Conception à couches des protocoles • Un protocole peut contenir un grand nombre de fonctionnalités • Pourrait être défini comme un seul programme, mais ceci serait excessivement complexe à • Implanter • Vérifier • Tester etc. • Le manque de modularité rendrait aussi difficile l’échange de modules préfabriqués entre compagnies INF6001 Chap 1

  20. Expressivité du concept de service • Si les couches sont bien conçues, il est possible d’exprimer le service fourni par une couche de manière à cacher le mécanisme interne de la couche • P. ex. une pile fournit 12 volt • C’est le service qu’elle fournit, qu’elle soit NiCa, NiMh, Alcaline, etc. – n’importe • Offrant ce service, elle peut être utilisée dans des moteurs qui ont besoin de ce voltage • Le moteur à son tour offre un service, identifié par des paramètres tels que puissance: p.ex. 0.05hp, n’importe son fonctionnement • Offrant ce service, il peut être utilisé dans des appareils qui ont besoin de cette puissance: p.ex. des modèles d’auto INF6001 Chap 1

  21. Expressivité du concept de service • Pile + moteur = force motrice • Moteur + modèle auto = jouet fonctionnel • Service sous-jacent + protocole = nouveau service • À chaque niveau, on peut oublier le service sous-jacent et utiliser directement le nouveau service INF6001 Chap 1

  22. Communication entre pairs The sales manager of company A may need to do a transaction with the sales manager of company B: I want to buy X amount of product P. Negotiation on prices, etc. may take place: Manager A Manager B negotiation protocol INF6001 Chap 1

  23. Fournisseur de service Since A and B are not in the same place, they must rely on some transport mechanism to transfer the Protocol Data Units (PDUs) between them Manager A Manager B PDUs Service Data Units SDUs Service Data Units SDUs Service Provider INF6001 Chap 1

  24. Couches The Service Provider itself must be implemented by communicating entities... it is implemented by admin assistants who write letters. These letters include the simple text provided by the managers into other text such as: Date... Dear Sir... Yours Sincerely... It is then passed to the mailing service provider. Manager A Manager B Service Data Units Service Data Units PDUs Assistant A Assistant B Service Data Units Service Data Units Service Provider INF6001 Chap 1

  25. Et encore couches The assistant interfaces directly with the secretaries. They include the letters into addressed envelopes and pass them on again to the lower layer service providers... Manager A Manager B Service Data Units Service Data Units PDUs Assistant A Assistant B SDU SDU Secretary A Secretary B SDU SDU Service Provider INF6001 Chap 1

  26. Ajout d’en-têtes (encapsulation) Manager A Header1 Payload PDUs Assistant A Header2 Header1 Payload Secretary A Header3 Header2 Header1 Payload Service Provider INF6001 Chap 1

  27. Layered Systems Concepts • At each layer, an entity has a message exchange with a peer entity on the other side. This exchange is made up of Protocol Data Units. • Hence the term peer protocol • Peer-to-peer implies that either side can initiate a session and has equal responsibility • Direct transmission of PDUs is not possible (except in extremely simple protocols). An underlying service provider must be invoked, by means of Service Data Units (SDUs). • The underlying service provider consists in its own turn of peer entities. To transmit the message coming from the protocol entity above, the lower level peer entity adds a header (or possibly a trailer) to the message. It then passes the message to the level below, who will add another header (trailer), etc. INF6001 Chap 1

  28. Concepts of Layered Systems (Continued . . .) • The message and all the headers (trailers) it has acquired will eventually be transmitted between the lowest layer peer entities. • As the message moves up on the other side, the headers (trailers) tacked on by peer entities are progressively ‘stripped’ at each level • secretaries will strip the envelopes, assistants will strip Date... Dear Sir... Yours Sincerely • highest level entity will eventually receive protocol unit sent by peer on the other side • Layering should be seen as a way to simplify the description of a protocol by decomposing it • Does not need to be implemented, although very often it is • Because it also simplifies the implementation, V&V, test, etc. INF6001 Chap 1

  29. Some layers can be skipped in certain cases • Layer n+2 • Layer n+1 • Layer n • Sometimes a layer is allowed to use directly services from two layers below. • This is done in order to simplify the description: clearly, in the example above, layer n+1 would have to be more complicated if it couldn’t be skipped. INF6001 Chap 1

  30. Comment choisir les couches? • Plusieurs critères de génie logiciel peuvent nous aider à trouver une bonne façon de décomposer un protocole complexe en couches • Du point de vue de la vérification, le critère le plus important est que les interfaces de service puissent être décrite de façon beaucoup plus simple que la somme des protocoles sous-jacents • Exemples à suivre • Ceci est d’ailleurs un principe commun en génie • P. ex. la spécification du service d’une pile électrique peut inclure le voltage et les dimensions • Pas normalement le fonctionnement interne: alcaline, NiCa, etc… • Le service offert par une couche d’isolation thermique peut être décrit en termes de RXX, le coefficient d’isolation,sans devoir dire quelle est la structure interne de la couche (fibre de verre, mousse…) INF6001 Chap 1

  31. Couches OSI Réf: http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Reseaux-generalites/Cours/4-3.htm INF6001 Chap 1

  32. Modèle de référence Open Systems Interconnection INF6001 Chap 1

  33. Fonctionnement Global INF6001 Chap 1

  34. OSI Lower Layers • Physical. Responsible for the actual transmission of bits over a physical medium (but the physical medium itself is below the physical layer). • Data Link. Responsible for the accurate transmission of data between two adjacent systems: error detection and correction, data sequencing. • Network. Addressing and routing. Responsible for data delivery to the final destination. • Transport. Responsible for reliable end-to-end data transmission. Creates and removes packets, i.e. the transport layer will take a byte stream (a logical message) from a session entity, packetize it for transmission by the network layer, and de-packetize it for delivery of a byte stream to a session entity. INF6001 Chap 1

  35. but-à-but transport layer transport layer netwk layer netwk layer network layer network layer data link layer data link layer data link layer data link layer physical layer physical layer physical layer physical layer liens adjacents OSI: Different scope of coverage by layers 1,2,3 and layer 4 and above INF6001 Chap 1

  36. Couche Transport Correspond à la couche TCP dans TCP/IP • Trois fonctionnalités de base: • Transforme les paquets en chaînes d’octets • Masque la paquetage aux couches supérieures • En dessus du transport, on ne considère plus les erreurs de transmission paquets • Ignore les relais intermédiaires • But à but, End-to-end • La couche transport est donc un pivot essentiel dans une pile de protocoles INF6001 Chap 1

  37. OSI Higher Layers • Session. It keeps track of the dialogue between peer entities. The entities can stop and restart the dialogue by agreement or in response to system failures, can make periodic checkpoints, etc. (e.g. I am stopping now, will restart later, make sure you know where I’ll restart) • Presentation. Responsible for the presentation of data. It negotiates with other layers how the information will be represented. (I will send you MS-Word files, OK? No, I don’t speak MS, can you send in PDF? Etc.) • Application. This layer provides facilities that are used directly by applications. E.g., directory services, remote procedure call, transaction control. INF6001 Chap 1

  38. Entités OSI N+1-Protocol Entity N+1-Protocol Entity N+1-PDUs N-SDUs N-SDUs N-SAP N-SAP N-Service Provider SAP: Service Access Point INF6001 Chap 1

  39. Entités et unité de données OSI N+1Protocol Entity N+1Protocol Entity N+1 PDUs N-SDUs N-SDUs N Protocol Entity N Protocol Entity N PDUs N-1 SDUs N-1 SDUs N-1 Service Provider N Service Provider INF6001 Chap 1

  40. Service Data Units (SDUs) • Request : Une entité sollicite un service • Indication : Une entité est informée d'une demande de service • Response : Une entité a rendu le service, si possible • Confirmation : Une entité est informée que le service a été rendu SAP SAP Service non confirmé REQUEST INDICATION Service confirmé CONFIRMATION RESPONSE INF6001 Chap 1

  41. Cas d’usage dans la couche transport OSI INF6001 Chap 1

  42. Exemple: Service de la couche Transport OSICas d’usage B B A A T-ConReq T-ConConf T-ConReq T-DiscInd T-ConInd T-ConResp T-ConInd T-DiscReq Connexion avec Succès AB Connexion refusée par B B B A A T-ConReq T-DatReq T-DatInd T-DiscInd Tentative de connexion de A refusée par le fourniss. de service Transfert Données AB A et B sont les SAPs des entités de protocoles A et B INF6001 Chap 1

  43. Service couche transport: déconnectionCas d’usage B A B A T-DiscReq T-DiscReq T-DiscReq T-DiscInd Les deux décident de déconnecter (collision) A décide de déconnecter B A T-DiscInd T-DiscInd Il y en a quelques autres… Le fournisseur de Service décide de déconnecter INF6001 Chap 1

  44. Service Transport: Échange typique (Nouvelle connexion) (Notes de cours du Prof. Bochmann, Ud’Ottawa) INF6001 Chap 1

  45. Two-way handshake • Note that only two messages are sufficient in order to establish connection • This is because TS assumes that the underlying services are ‘perfect’, this means that all messages are (eventually) delivered • So a last message from initiator back to responder is unnecessary • In fact, this fact also determines other aspects of this SDU exchange INF6001 Chap 1

  46. Décomposition et fonctionnementde la couche Transport OSI INF6001 Chap 1

  47. Protocoles et interfaces SAP N Protocole Couche N Interface entre couche N et couche N-1 SAP N-1 • Il y a une interface logique entre la couche N et la couche N-1 Couche N décomposée INF6001 Chap 1

  48. Fonctionnement de protocoles et interfaces • Le protocole de couche N génère et répond aux unités de service (SDUs) • allant au • provenant de SAP N • Il génère et répond aussi aux unités de protocoles (PDUs) • allant au • provenant de l’interface avec SAP N-1 • L’interface: encapsuler, décapsuler • Prend les unités de protocoles (PDUs) générées par le protocole N et les encapsule pour former des unités de service(SDUs) dirigées au SAP N-1 • Prend les unités de service générées (SDUs) par le protocole N-1 et les décapsule pour générer des unités de protocole (PDUs) dirigées au protocole N INF6001 Chap 1

  49. La couche transport OSI et ses unités de données pour la phase connexion Unités service couche transport: Ce schéma s’applique à toutes les couches T-SAP T-ConReq, T-ConResp, T-ConInd, T-ConConf Protocole Couche T CR, CC Interface Avec couche réseau: Encapsulation, décapsulation Unités de service couche Réseau N-SAP N=Network=Réseau CR et CC sont les PDUs: ils sonttransmis vers ou des couches inférieures encapsulés dans N-DatReq¸ N-DatInd, p.ex. N-DatReq(CR, …) INF6001 Chap 1

  50. Idéalement, la transmission des PDU est directe T-ConReq T-ConInd T-SAP T-SAP CR Protocole Transport Protocole Transport INF6001 Chap 1

More Related