Protocol Engineering

Transkript

1 Brandenburgische Technische Universität Cottbus Lehrstuhl Rechnernetze und Kommunikationssysteme Entwurf und Validierung von Protokollen und Verteilten Systemen Prof. Dr.-Ing. Hartmut König Lehre BTU Cottbus, LS Rechnernetze und Kommunikationssysteme, Lehrstuhlinhaber: Prof. Dr.-Ing. H. König Cottbus, Postfach ,Telefon: 0355/ Fax: 0355/

2 II.3.5 Temporale Logiken Abschnitt 7.8 II.3/2

3 Temporale Logiken Literatur Clark, E.; Grumberg, O.; Peled, D.: Model Checking. MIT Press, Holzmann, G.J.: The SPIN Model Checker Primer and Reference Manual. Addison- Wesley, 2004 II.3/3

4 A) Beschreibungsprinzip II.3/4

5 Temporale Logiken Temporale Logiken sind Erweiterungen der Aussagenlogik und der Prädikatenlogik durch Operatoren, die die Formulierung von Aussagen mit Bezug auf die Zeit gestatten. nicht die absolute Zeit interessiert, sondern die zeitliche Folge, in der sich die Dinge ereignen beschreiben Eigenschaften, die das System/Protokoll erfüllen soll Einhaltung der Eigenschaften im Entwurf wird durch temporallogisches Schließen oder Model Checking überprüft Wichtigste deskriptive Beschreibungsmethode für Kommunikationsprotokolle!!! II.3/5

6 Systemanforderungen Systemanforderungen, die mittels Temporaler Logiken beschrieben werden, unterscheiden sich in Sicherheitseigenschaften besagen, dass in dem zu beschreibenden System/Protokoll bestimmtes, unerwünschtes Verhalten nicht eintreten wird wenn etwas passiert, dann handelt es sich um etwas Erwünschtes Lebendigkeitseigenschaften sichern, dass die spezifizierten Ereignisse und Zustände irgendwann tatsächlich eintreten beschreiben, was passieren muss II.3/6

7 B) Arten temporaler Logiken II.3/7

8 Arten Temporaler Logiken Es gibt verschiedene Arten temporaler Logiken, die sich in Abhängigkeit von den Eigenschaften, die sie zu beschreiben gestatten, in ihrer Ausdruckskraft unterscheiden. Wichtigste Unterscheidung Lineare temporale Logiken (Linear-time temporal logics) Verzweigende temporale Logiken (Branching-time temporal logics) II/8

9 Lineare Temporale Logiken Lineare temporale Logiken modellieren das Systemverhalten als lineare Folge von Zuständen. Es gibt nur ein zeitliches Verhalten Jeder Moment/Zustand hat einen eindeutigen Nachfolger Unendliche Folge von Zuständen Beispiel: Linear Temporal Logics (LTL) bevorzugter Einsatz: Software-Verifikation II.3/9

10 Verzweigende Temporale Logiken Verzweigende temporale Logiken lassen in einem gegebenen Zustand alternative Verhalten zu. Verschiedene zeitliche Abläufe Zustandsbaum Unendliche Folge von Zuständen Beispiel: Computational Tree Logic (CTL) bevorzugter Einsatz: Hardware-Verifikation II.3/10

11 C) Beispiel-Logik II.3/11

12 Beispiel-Logik Lineare temporale Logik, die Aussagen zur Gegenwart und Zukunft gestattet. Aussagen zur Gegenwart - Negation - Konjunktion - Disjunktion - Implikation - Äquivalenz Aussagen zur Zukunft siehe folgende Folien II.3/12

13 Aussagen zur Zukunft (1) - von nun an (henceforth) / immer (always) Sei p eine Aussage, dann bedeutet dass die Aussage jetzt und in der Zukunft wahr ist ( Garantie). p Beispiel: (XDATrequ_1 phase CONNECT) II.3/13

14 Aussagen zur Zukunft (2) - letztendlich (eventually) Sei p eine Aussage, dann bedeutet p dass p jetzt wahr ist oder irgendwann in der Zukunft wahr wird. Beispiel: (XDATrequ XDATind) II.3/14

15 Aussagen zur Zukunft (3) - nächster (next) Sei p eine Aussage, dann bedeutet p dass, wenn es einen nächsten Zustand gibt, p in diesem Zustand wahr ist. Beispiel: (phase = DATA TRANSFER XABORTind O(phase CONNECT)) II.3/15

16 Aussagen zur Zukunft (4) U - solange bis (until) Seien p und q Aussagen, dann bedeutet p U q dass es einen Zustand gibt, in dem q gilt. Solange dieser Zustand nicht erreicht ist, gilt p. Beispiel: (phase DATA TRANSFER U (S.XDISind S.XABORT)) II.3/16

17 Aussagen zur Zukunft (5) W - solange nicht (unless) Seien p und q Aussagen, dann bedeutet pwq dass p solange gilt bis q wahr wird, jedoch muss q nicht notwendigerweise wahr werden. Beispiel: (S.XDATrequ (S.XDATconf Wstate break)) II.3/17

18 Bedeutung der LTL-Operatoren p p p puq pwq oder II.3/18

19 Beispiel: XDT-Verbindungsaufbau ((S.XDATrequ S.XDATrequ.sequ 1) phase CONNECT) ((S.XDATrequ S.XDATrequ.sequ>1) phase DATA TRANSFER) ((S.XDATrequ S.XDATrequ.sequ 1) (S.XDATconf phase DATA TRANSFER) S.XABORTind) ((S.XDATrequ S.XDATrequ.sequ=1) (R.XDATind S.XABORTind)) Aussagen (1) + (2): Sicherheitseigenschaften Verbindungsaufbau nur in der CONNECT-Phase Aussagen (3) + (4): Lebendigkeitseigenschaften Protokollfortschritt II.3/19

20 D) Diskussion II.3/20

21 Temporale Logiken Vorteile: explizite Spezifikation der zu erfüllenden Systemanforderungen Allgemeingültigkeit kann formal bewiesen werden Inkonsistenzen können aufgedeckt werden Nachteile: Übergang zur Implementierung kompliziert fehlende Werkzeugunterstützung hoher Einarbeitungsaufwand Vorkenntnisse erforderlich Für praktischen Protokollspezifikationen kaum genutzt!!! Anwendung in Kombination mit anderen Methoden insbesondere Model Checking II.3/21

22 II.3.6 Hybride Methoden Abschnitt 7.4 II.3/22

23 Hybride Methoden Keine Beschreibungsmethode oder FDT erfüllt vollständig alle Anforderungen der Protokollbeschreibung wie sie zu Beginn dieses Kapitels diskutiert worden sind. Dies schränkt ihre Anwendbarkeit in der Praxis. Deshalb werden Hybride Methoden eingesetzt, die verschiedene Beschreibungsmethoden kombinieren, um von ihren Vorteilen zu profitieren und für ihre Unzulänglichkeiten zu kompensieren. Beispiele: - EFSM + Sprachen - EFSM + Petri Netze + Temporale Logiken - ctla (siehe Buch Abschnitt 8.4) Alle FDTs basieren mehr oder weniger auf hybride Ansätzen!!! II.3/23

24 II.3.7 Datenbeschreibung Beispiel: ASN.1 (Abstract Syntax Notation One) Abschnitt 8.5 II.3/24

25 Struktur einer Protokollbeschreibung Zwei Bestandteile: Beschreibung der Datenformate Grundlage/Voraussetzung der Funktionsweise von Protokollen Beschreibung der Protokollablaufs Hauptteil der Beschreibung In diesem Kapitel betrachtet II.3/25

26 ASN.1 Literatur O. Dubuisson: ASN.1 - Communication between heterogeneous systems. Morgan Kaufmann Publishers, 2000 e-tutorial II.3/26

27 Datenbeschreibung in Protokollen Für die Datenbeschreibung von Protokollen wurden ursprünglich Sprachmittel höherer Programmiersprachen verwendet, die z. T. durch Darstellungsmittel für abstrakte Datentypen erweitert wurden. Estelle: Pascal-Datentypen z.t. zu detailliert SDL: Abstrakte Datentypen relativ aufwendig Lotos: Abstrakte Datentypen / ACT ONE sehr aufwendig Unabhängig von der FDT-Entwicklung hat ASN.1 als Beschreibungssprache für Datenformate in der Telekommunikation eine breite Anwendung gefunden. flexibler weniger aufwendig II.3/27

28 A) Bedeutung und ursprünglicher Einsatz von ASN.1 II.3/28

29 Entwicklung von ASN.1 Beginn der Entwicklung: Mitte der 80er Jahre Beschreibungssyntax X.409 der CCITT Entwickler: CCITT / später von ISO übernommen IS 8824: Abstract Syntax Notation One IS 8825: Basic Encoding Rules Sprachüberarbeitungen: 1994, 1997, 2002 II.3/29

30 Bedeutung von ASN.1 (ursprüngliches) Ziel: Beschreibung abstrakter Syntaxen gleiche Interpretation der Daten in verteilten Systemen später Nutzung zur Beschreibung von Datenformaten jetzt bevorzugt genutzt Integration in FDTs (z. B. SDL) auch Nutzung in der Internetwelt z. B. DNS, Netzmanagement (SNMP, LDAP), X.509, Abrechnung von Roaming- Gebühren GSM und UMTS ASN.1 ist eine wichtige Beschreibungsnotation für Datenformate von Kommunikationsprotokollen und Verteilten Systemen!!! II.3/30

31 Einschub: Prinzip der Nutzung abstrakter Syntaxen (1) Lokale Syntax_1 Verteilte Anwendung Abstrakte Syntax Lokale Syntax_2 Kodierungsregeln Transfer- Instanz Darstellungskontext Transfer- Instanz OSI-Schicht 7 OSI-Schicht 6 Host_1 Transfersyntax Host_2 II.3/31

32 Abstrakte vs. Transfersyntax Abstrakte Syntax Definiert eine generische Darstellung für die Datentypen und Werte einer verteilten Anwendung, die unabhängig ist von ihrer konkreten Kodierung in den einzelnen Rechnern (lokale Syntax) Transfersyntax Syntax für den Datenaustausch zwischen den kommunizierenden Rechnern. II.3/32

33 Einschub: Prinzip der Nutzung abstrakter Syntaxen (2) APDU::=SEQUENCE{ header Headertype user data OCTET STRING} ASN.1 TYPE apdu= RECORD h: header user_data: ARRAY[1..512] OF CHAR END Lokale Syntax A typedef struct { hdr_type h char* user_data } Lokale Syntax B Modula Kodierung/ Dekodierung Basic Encoding Rules Transfersyntax C Kodierung/ Dekodierung II.3/33

34 Kodierungsregeln ASN.1 schreibt die Transfersyntax nicht vor!!! Kodierungsregeln Basic Encoding Rules (BER) Packed Encoding Rules (PER) Canonical Encoding Rules (CER) Distinguished Encoding Rules (DER) XML Encoding Rules (XER) II.3/34

35 Anwendungsbereiche eines ASN.1-Compilers ASN.1 Spezifikation Parameter ASN.1- Compiler Kodierer/ Dekodierer Transfersyntax Höhere Programmiersprache II.3/35

36 B) Prinzip des ASN.1 II.3/36

37 Prinzip des ASN.1 ASN.1 ist keine formale Beschreibungstechnik, wie die anderen hier diskutierten Sprachen. Es hat eine informale Semantik. In der Vorlesung wird die Sprache nicht detailliert behandelt. ASN.1 definiert nur Datenformate; keine Operationen! Definition neuer Datentypen auf der Basis einfacher und zusammengesetzter Datentypen Typ-Deklarationen Kennzeichnung der Datentypen zur Erkennung durch Tags In der Zwischenzeit automatisiert II/37

38 Typdefinitionen / Einfache Typen Die Typdefinition ist neben der Wertdefinition eines der grundlegenden Elemente in einer ASN.1-Beschreibung. Beispiel: Role::=BOOLEAN Einfache Typen BOOLEAN, INTEGER, BIT STRING, OCTET STRING, REAL, ENUMERATED und NULL NULL Signal II.3/38

39 Zusammengesetzte Typen ASN.1 SEQUENCE SEQUENCE OF SET SET OF CHOICE Subtypen entspricht record, struct array, [ ] type set set (nur gleicher Typ) union z.b. INTEGER(0..99) II.3/39

40 II.3.8 UML-2 (Unified Modeling Language) II.3/40

41 UML-2 Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Softwaresysteme. definiert Notationselemente für die statische und dynamische Modellierung enthält auch Sprachelemente für die Beschreibung von Protokollen Protokollautomaten Sequenzdiagramme UML-2 passt die Sequenzdiagramme weitgehend an MSC II.3/41

42 UML-Diagramme (1) UML 2 unterscheidet 13 verschiedenen Diagramm-Typen. Strukturdiagramme beschreiben, welche Systemelemente/-komponenten modelliert werden Verhaltensdiagramme beschreiben, das Verhalten und die Abläufe im System unterstützt alle Elemente für Protokollbeschreibung!!! auch in verschiedenen Entwurfsphasen (z.b. Use Cases) II.3/42

43 UML-Diagramme (2) Strukturdiagramme Klassendiagramm Kompositionsstrukturdiagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Paketdiagramm Profildiagramm Verhaltensdiagramme Anwendungsfalldiagramm (Use Cases) Aktivitätsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsdiagramm Zeitverlaufsdiagramm Zustandsdiagramm Sonderfall: Protokollautomat II.3/43

44 EFSM/FSM der XDT-Instanzen II.3/44

45 UML-Sequenzdiagramm XDT- Datenübertragung (Ausschnitt) II.3/45

46 UML vs. FDTs UML Allgemeine Modellierungssprache Keine formale Semantik Komplexe Sprache Viele Anwendungsbereiche Ziel: Modellentwicklung und weniger die Dokumentation eines konkreten Entwurfsprozesses Modelle können auf andere Sprachen und Plattformen abgebildet werden FDTs Stärker auf ein bestimmtes Anwendungsgebiet ausgerichtet Formal Semantik Semantisches Modell bestimmt und begrenzt die Modellierungsfähigkeiten Dokumentiert einen konkreten Entwurfsprozess Abbildung auf andere Sprachen ist komplizierter Verifikationsunterstützung II/46

47 Was will UML nicht sein? 1 UML ist nicht perfekt nicht vollständig keine Programmiersprache keine rein formale Sprache nicht spezialisiert auf ein Anwendungsgebiet kein vollständiger Ersatz für Textbeschreibung und vor allem keine Methode oder kein Vorgehensmodell. UML-2 ist keine formale Beschreibungstechnik!!! Protokollbeschreibung braucht auch nicht zwingend Objekt- Orientierung!!! 1) entnommen: C. Rupp et al.: UML 2 glasklar. Hanser 2005 II.3/47

48 UML-2 für die Protokollbeschreibung? UML wird von mehr Anwendern genutzt als bisherige FDTs!!! Nutzung von UML-2 bietet die Chance einer breiteren Akzeptanz formaler Beschreibungen von Protokollen / verteilten Systemen!!! und damit der Weiterentwicklung ingenieurmäßiger Methoden Ansätze für die Abbildung von UML 2 auf formale Beschreibungstechniken Abbildung einer Teilmenge von UML-Diagrammen auf FDTs automatische Analysen Kopplung von UML mit einer formalen Beschreibungstechnik UML Profile for SDL (Z.109) Definition einer formalen Semantik für eine Untermenge von UML II.3/48