Entwicklung von Telekommunikationssystemen

Präsentation zum Thema: "Entwicklung von Telekommunikationssystemen"—  Präsentation transkript:

1 Entwicklung von Telekommunikationssystemen
Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg Sommersemester 2000 Copyright © Stefan Leue 2000

2 Übersicht 1. Einführung in den Software-Entwurfsprozess
2. Anforderungsspezifikation mit Zustandsmaschinen 3. Anforderungsspezifikation mit Linearer Temporaler Logik 4. Automatenbasiertes Model Checking 5. Die Modellierungssprache Promela und der SPIN Model Checker 6. Effizienzsteigernde Massnahmen 7. Anwendungsbeispiele von SPIN Model Checking 8. Eine visuelle Entwicklungsumgebung für Promela/Spin 9.Verwandte, semi-formale Modellierungsmethoden Entwurf von Telekommunikationssystemen

3 Übersicht 1. Einführung in den Software-Entwurfsprozess
2. Anforderungsspezifikation mit Zustandsmaschinen 3. Anforderungsspezifikation mit Linearer Temporaler Logik 4. Automatenbasiertes Model Checking 5. Die Modellierungssprache Promela und der SPIN Model Checker 6. Effizienzsteigernde Massnahmen 7. Anwendungsbeispiele von SPIN Model Checking 8. Eine visuelle Entwicklungsumgebung für Promela/Spin 9.Verwandte, semi-formale Modellierungsmethoden Entwurf von Telekommunikationssystemen

4 Telekommunikationssysteme
Verteilte Systeme Ziel: Daten-, Sprach- und Videokommunikation über grosse Distanzen hinweg zu ermöglichen Beispiele (im engeren Sinne): Telefon analog (POTS) oder digital (z.B. ISDN) Intelligent Networks (IN) Advanced Intelligent Networks (AIN) Active Networks Mobilkommunikation (z. B. GSM/UMTS) Breitbandige Verteilte Anwendungen Beispiele (im weiteren Sinne): Kommunikationsprotokolle (z.B. SS7, TCP/IP, etc.) Verteilte ORBs (z.B. CORBA General Inter ORB Protocol) Systeme der Prozesskommunikation (z.B. Automobil-Elektronik) Eingebettete Systeme Entwurf von Telekommunikationssystemen

5 Relevanz von Software Telekommunikationssysteme bestehen aus Hardware und Software Software bestimmt etwa 60-80% des Entwicklungsaufwands Beispiele Nortel Networks, DMS-100 Vermittlungsanlage c.a Mio Codezeilen Lebenszyklus: Entwicklung seit 1981 c.a Software-Entwickler jeweils gleichzeitig Lucent Technologies 5ESS c.a. 10 Mio Codezeilen 30 % des Codes läuft im Hintergrund, um SW-Fehler aufzufangen Mean Time Between Failure: c.a. 7 Jahre (läge bei wenigen Stunden ohne Auffangcode) Lucent PathStar (telephony over IP) einige hunderttausend Zeilen Code Call Processing und Features: einige Zeilen Code Entwurf von Telekommunikationssystemen

6 Softwarekrise? Studie des US Government Accounting Office - 1979
9 contracts, total $7 mio Entwurf von Telekommunikationssystemen

7 Softwarekrise? Standish Group ( , nach [Pfleeger]), 350 Firmen mit über 8000 Software Projekten 31% der Projekte wurden vor Vollendung abgebrochen 9% der Projekte in grossen Firmen wurden im Rahmen der projektierten Dauer und Kosten beendet, (16% in kleineren Firmen) Übersicht von IEEE Software (1995) 30% aller Softwareprojekte werden abgebrochen 50% aller Projekte überschreiten um mindestens 150% das Budget nur 60% der gewünschten Funktionalität sind in den Produkten enthalten 9 contracts, total $7 mio Entwurf von Telekommunikationssystemen

8 Softwarekrise? Gründe für das Scheitern von Softwareprojekten (Standish Group, 1995, nach [Pfleeger]): unvollständige Anforderungen: 13,1% mangelnde Einbeziehung der Benutzer: 12,4% Mangel an Ressourcen: 10,6% unrealistische Erwartungen: 9,9% Mangel an Managementunterstützung: 9,3% Sich ändernde Anforderungen und Spezifikationen: 8,7% Mangel an Planung: 8,1% System nicht weiter benötigt: 7,5% Herausfindung (elicitation), Verstehen, Dokumentation und Spezifikation von Anforderungen leisten entscheidenden Beitrag zu den meisten oben genannten Gründe für das Scheitern von Softwareprojekten Entwurf von Telekommunikationssystemen

9 Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen

10 Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen

11 Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen

12 Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen

13 Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen

14 Symptome der Softwarekrise
Softwareprojekte überschreiten geplante Zeit- und Budgetgrenzen Softwareprojekte werden vorzeitig abgebrochen Softwareprodukte beinhalten nicht die gewünschte Funktionalität Softwareprodukte sind fehlerbehaftet Entwurf von Telekommunikationssystemen

15 Warum ist die Konstruktion von SW so schwierig?
Kein vergleichbares System bisher konstruiert Problem nie vorher gelöst Lösung unbekannt Annahmen über das System basieren auf reinen Vermutungen Schwierigkeit, den notwendigen Zeit- und Personalbedarf bis zur Vollendung des Projektes richtig einzuschätzen Anforderungen nicht richtig verstanden Anforderungen ändern sich während des Lebenszyklusses “Als ich das Produkt sah wusste ich, dass es nicht das war, was ich eigentlich wollte” Komplexe Interaktionen zwischen Diensten / Komponenten Feature Interaction: call forwarding / call screening Umkehrschub vs. unbeabsichtigter Aktivierung Entwurf von Telekommunikationssystemen

16 Warum ist die Konstruktion von SW so schwierig?
Natur der Systeme Deadlocks für nebenläufige Systeme Zeitproblems für Echtzeitsysteme Performanzprobleme für Informationssysteme Software ist leicht formbar verleitet zu “code-and-fix” Entwurf von Telekommunikationssystemen

17 Warum ist die Konstruktion von SW so schwierig?
Software ist diskret “When software fails, it invariably fails catastrophically. This awful quality is a reflection of the lack of continuity between successive system states in executing software. If the preceeding state is correct, there is no inherent carry over of even partial correctness into the next succeeding state.” (W. Royce, zitiert nach [Rushby]) “The problem … is that computer hardware and software are discrete systems: their behavior is determined by a succession of discrete state changes. The succession of states need not produce behavior that varies smoothly or continuously, instead it can exhibit discontinuities and abrupt transitions. The ability to select among many alternative courses of action is a source of the power … provided by computer systems, but it is also the reason why their behavior is hard to predict and to validate.” [Rushby] Konsequenzen Korrektheit kann nicht approximiert werden unvollständige Tests haben nur bedingte Aussagekraft Vergleich mit kontinuierlichen Artifakten Hängebrücke, bei der 1% der Kabel in dem Seil defekt sind Programm, in dem 1% der Instruktionen falsch sind Entwurf von Telekommunikationssystemen

18 Software Engineering Konsequenz Vorteile
Versuch, den Software-Entwurf auf eine rigorose, ingeniersmässige Grundlage zu stellen Einführung von Lebenszyklus-Modellen Einführung von Software-Prozessmodellen wohldefinierte und reproduzierbare Transformationen auf jeder Prozesstufe Vorteile klare Definition separater Aufgaben  “seperation of concerns” Teamarbeit Reproduzierbarkeit Zerteilung der Komplexität des Entwurfsproblems in kleinere Einheiten Spezifikation und Dokumentation Möglichkeit, Verifikation/Validation, Prototyping und evolutionäre Entwurfsmodelle einzuführen Entwurf von Telekommunikationssystemen

19 Life-cycle Model: Waterfall
Entwurf von Telekommunikationssystemen

20 Life-cycle Model: Waterfall
System Design overall design HW/SW split informal, with cusotmer System design Entwurf von Telekommunikationssystemen

21 Life-cycle Model: Waterfall
SW Requirements “what” the system has to do functional/non-functional observable behaviour SRS document System design Requirements SRS Entwurf von Telekommunikationssystemen

22 Life-cycle Model: Waterfall
Design “how” the system is doing it architectural design detailed design design document System design Requirements SRS Design Design Entwurf von Telekommunikationssystemen

23 Life-cycle Model: Waterfall
System design Module Implementation and Test implement module structure test modules in isolation Requirements SRS Design Design Implementation Entwurf von Telekommunikationssystemen

24 Life-cycle Model: Waterfall
System design Integration integrate modules integration testing customer acceptance tests Requirements SRS Design Design Implementation Integration Entwurf von Telekommunikationssystemen

25 Life-cycle Model: Waterfall
System design Maintenance deploy product corrective, adaptive, perfective maintenance Requirements SRS Design Design Implementation Integration Maintenance Entwurf von Telekommunikationssystemen

26 Modifiziertes Wasserfallmodell
Entwurf von Telekommunikationssystemen

27 Zeit/Resourcen pro Stufe
Entwurf von Telekommunikationssystemen

28 Zeit/Resourcen pro Stufe
Entwurf von Telekommunikationssystemen

29 Relevanz früher Entwurfsphasen
Anteil von Anforderungsfehlern an der Gesamtzahl der Entwicklungsprobleme (nach [Pfleeger]) “there are usually three design faults for every two coding faults” (Boehm and Papaccio, 1988) zurückzuführen auf Anforderungsfehler? Studie von Jones und Thayer 35% der Fehler beruhen auf Entwurfsfehlern für Projekte mit einer Grösse von ausgelieferten Quellcodeinstruktionen 10% der Fehler beruhen auf Anforderungsfehlern und 55% auf Entwurfsfehlern für Projekte mit einer Grösse von Instruktionen Basili und Perricone (1984): 48% aller Fehler in Softwareprojekten mittlerer Grösse auf inkorrekte oder misinterpretierte funktionale Spezifikationen oder Anforderungen zurückzuführen Beizer: “Requirements … are a major source of expensive bugs. The range is from a few percent to more than 50% … What hurts most ... is that they’re the earliest to invade the system and the last to leave. It’s not unusual for a faulty requirement … only to be caught after hundreds of sites have been installed.” Entwurf von Telekommunikationssystemen

30 Relevanz früher Entwurfsphasen
Davis’ Hypothesen bezüglich der Wichtigkeit von Anforderungsspezifikationen ([Davis]) Hypothese 1: Je später im Lebenszyklus ein Fehler entdeckt wird, desto kostspieliger ist seine Behebung Entwurf von Telekommunikationssystemen

31 Relevanz früher Entwurfsphasen
Mögliche Erklärung: Fehler werden erst sehr viel später nach ihrer Entstehung entdeckt Zusätzliche Kosten später Entdeckung: nicht nur Behebung des ursprünglichen Fehlers, aber auch aller Folgefehler Beobachtung von Mizuno: korrekte Spezifikation fehlerhafte Korrekter Entwurf Funktionalität korrektes Programm fehlerhafter Programmier- fehler korrigierbare Fehler Programm bas. auf fehlerh. Entwurf bas. nicht erkennbare Implementierung Testen Anwendungsproblem Entwurf von Telekommunikationssystemen

32 Relevanz früher Entwurfsphasen
Hypothese 2: Viele Fehler bleiben unerkannt und werden erst spät nach ihrer Verursachung entdeckt Boehm: 54% aller Fehler, die bei TRW untersucht wurden, wurden erst nach der Implementierungs- und Modultest-Stufe im Lebenszyklus entdeckt Hypothese 3: Es werden viele Anforderungsfehler gemacht DeMarco: 56% aller entdeckter Software-Fehler lassen sich auf Anforderungsfehler zurückführen Beispiele, die zeigen, dass die automatisierte Analyse von zuvor manuell inspizierten Spezifikationen im militärischen Bereich bei maschineller Analyse zahlreiche Fehler entdecken lassen früher genannte Zahlen Entwurf von Telekommunikationssystemen

33 Relevanz früher Entwurfsphasen
Hypothese 4: Anforderungsfehler sind typischerweise inkorrekte Fakten, Auslassungen, Inkonsistenzen oder Mehrdeutigkeiten Analyse der Navy A-7E Spezifikation,77% der Fehler sind nicht reine Schreibfehler 49% inkorrekte Fakten 31% Auslassungen 13% Inkonsistenzen 5% Mehrdeutigkeiten Hypothese 5: Anforderungsfehler können entdeckt werden Effektivität von Inspektionen (manuell oder maschinell) Umfangreiche Fallstudien mit automatischen Analysewerkzeugen, u.a. REVS, SMV, SPIN Entwurf von Telekommunikationssystemen

34 Relevanz früher Entwurfsphasen
Konsequenzen H3 und H4: Anfoderungsfehler werden in grosser Zahl gemacht H2: Viele dieser Fehler werden nicht früh entdeckt H5: Viele dieser Fehler könnten früh entdeckt werden H1: Anforderungsfehler tragen massgeblich zu explodierenden Softwarekosten bei Auswirkungen Die resultierenden Softwareprodukte erfüllen möglicherweise nicht die Anforderungen der Benutzer Mehrdeutige Anforderungsspezifikationen führen zu juristischen Auseinandersetzungen zwischen Auftraggebern und Auftragnehmern Gründliches testen kann erschwert oder unmöglich gemacht werden Ressourcen können durch die Konstruktion falscher Systeme verschwendet werden Entwurf von Telekommunikationssystemen

35 Aktivitäten in der Anforderungsphase
Ausgangspunkt Systemspezifikation (HW und SW) Kunden- oder Benutzeranforderungen (abstrakt) Aktivitäten (nach [Kotonya and Sommerville]) Anforderungsermittlung (elicitation) Interviews, Szenarios, Marktbeobachtungen etc. Anforderungsanalyse und Vereinbarung Bestimmung, welche der möglicherweise wiedersprüchlichen Anforderungen wichtig sind Anforderungsdokumentation und Spezifikation Allgemeinverständliches Anforderungsdokument Nicht-formale oder formale Spezifikation Validation der Anforderungen Konsistenz Vollständigkeit Entsprechung der abstrakten Kunden- oder Benutzeranforderungen Entwurf von Telekommunikationssystemen

36 Grobes Prozessmodell für die Anforderungsphase
Kunden- oder Be- nutzeranforderungen (abstrakt) Anforderungs- analyse und Vereinbarung Anforderungs- dokumentation und Spezifikation Validation Anforderungs- ermittlung Vereinbarte und Validierte Anforderungen Entwurf von Telekommunikationssystemen

37 Anforderungen Anforderungsspezifikation (auch Pflichtenheft oder Lastenheft genannt) ist häufig die Basis einer vertraglichen Vereinbarung zwischen Softwareersteller und dem Kunden Nach ANSI/IEEE Standard “Glossary of Software Engineering Terminology” Requirement: “… (2) A condition or capability that must be met or professed by a system component to satify a contract, standard, specification or other formally imposed document.” Requirement Specification: “A specification that sets forth the requirements for a system of system component; … typically included are functional requirements, performance requirements, interface requirements, design requirements and development standards.” Nach [Davis] “A software requirements specification is a document containing a complete specification of what the system will do without saying how it will do that.” Entwurf von Telekommunikationssystemen

38 Copyright © Prentice-Hall Inc., 1993 1990
Was / Wie Dilemma Copyright © Prentice-Hall Inc., Entwurf von Telekommunikationssystemen

39 Anforderungsspezifikation
Vollständige Beschreibung des extern sichtbaren Verhaltens System Schnittstelle Umgebung Entwurf von Telekommunikationssystemen

40 Struktur einer Anforderungsspezifikation
Unterschiedliche, teils standardisierte Schablonen Beispiel: ANSI/IEEE STD Standard Einführung (Zweck, Definitionen, Referenzen, Übersicht) Allgemeine Beschreibung (Funktionen des Produktes, Benutzercharakteristika, Allgemeine Nebenbedingungen, Annahmen und Abhängigkeiten) Spezifische Anforderungen Funktionale Anforderungen (Eingabe, Verarbeitung, Ausgabe) Anforderungen and externe Schnittstellen Performanzanforderungen Entwurfsnebenbedingungen Attribute (Verfügbarkeit, Sicherheit, Wartbarkeit) Sonstige Anforderungen Entwurf von Telekommunikationssystemen

41 Sprachen für Anforderungsspezifikationen
Natürliche vs. formale Notationen natürliche Sprache “wenn der Telefonhöhrer aufgenommen wird, dann ertönt ein Wählton” + ausdrucksstark + verstanden von allen am Entwicklungsprozess beteiligten Personen - Mehrdeutigkeiten formale Notationen und Sprachen (besitzen mathematische Semantik) + eindeutig + weitgehend maschinell analysierbar - ausdrucksschwach (besonders wenn maschinell analysierbar) - werden nur von einem Teil der involvierten Personen beherrscht Entwurf von Telekommunikationssystemen

42 Sprachen für Anforderungsspezifikationen
Evaluierungskatalog für Spezifikationssprachen nach Ardis (siehe [Pfleeger], 4.11) Anwendbarkeit Implementierbarkeit (kann leicht Code erzeugt werden) Test- und Simulierbarkeit Überprüfbarkeit (u.a. Lesbarkeit für Anwendungsfachleute) Pflegbarkeit Modularität Ebene der Abstraktion und Ausdrucksfähigkeit (wie gut können die Objekte in der Spezifikation die Objekte in der Anwendungwelt beschreiben) logische Vollständigkeit (gibt es formale Semantik der Sprache so dass Inkonsistenzen entdeckt werden können) Verifizierbarkeit Laufzeit-Sicherheit Entwurf von Telekommunikationssystemen

43 Sprachen für Anforderungsspezifikationen
Evaluierungskatalog für Spezifikationssprachen nach Ardis (siehe [Pfleeger], 4.11) - Fortsetzung Ausgereiftheit der Werkzeuge Lockerheit (sind Unvollständigkeiten und Nichtdeterminismus erlaubt) Lernkurve Technische Ausgereiftheit (Zertifizierung oder Standardisierung) Datenmodellierung (Repräsentation von Daten und Zusammenhängen) Disziplin (zwingt die Technik den Benutzer, wohl-strukturierte, verständliche und sich gut verhaltende Spezifikationen zu schreiben) Spezifikationssprachen sind domänen- und problemspezifisch Entwurf von Telekommunikationssystemen

44 Eigenschaften von Anforderungsspezifikationen
korrekt (correct) Alle Fakten, die in der Anforderungsspezifikation genannt werden, entsprechen einer von dem zu entwerfenden System geforderten Eigenschaft. Gegenbeispiel Eine Spezifikation besagt, dass der Angerufene bei Auflegen des Hörers durch den Anrufer einen Wählton bekommt, wohingegen die Systemanforderungen verlangen, dass der Angerufene in dieser Situation einen Besetztton bekommt. Entwurf von Telekommunikationssystemen

45 Eigenschaften von Anforderungsspezifikationen
eindeutig (unambiguous) Alle in der Anforderungsspezifikation genannten Fakten haben eine einzige Interpretation Natürlichsprachliche Beschreibungen bergen häufig Quellen für Mehrdeutigkeiten Bei bis zu 60 km/h soll der Tempomat deaktiviert bleiben Bei bis zu 12 Flugzeugen auf dem Kontrollschirm soll das kleine Darstellungsformat benutzt werden, andernfalls das grosse Format Um Übersichtlichkeit zu gewährleisten ist es unerheblich, ob dies als  12 oder  12 interpretiert wird Problem aber, wenn zwei unterschiedliche Entwicklungsteams für die zwei Darstellungsformate zuständig sind aber keine Einigkeit über die Behandlung des Falls =12 existiert -> möglicherweise schwarzer Bildschirm in diesem Fall Entwurf von Telekommunikationssystemen

46 Eigenschaften von Anforderungsspezifikationen
vollständig (complete) Definition 1: Alles, was das System können soll, ist durch die Spezifikation ausgedrückt. Heisst, dies, dass eine Spezifikation ausdrücken muss, wie sich das System nicht verhalten soll? möglicherweise aufgrund der Anzahl der möglichen Systemverhalten schwer auszudrücken formale Spezifikationen können helfen, dies zu erreichen, z.B. ... aber es kann gute Gründe dafür geben, dass auch andere Telefone läuten Automaten- und Logikspezifikationen erfüllen aufgrund ihrer semantischen Modelle diese Anforderung (“closed world assumption”) Entwurf von Telekommunikationssystemen

47 Eigenschaften von Anforderungsspezifikationen
vollständig (complete) Definition 2: Die Antworten des Softwaresystems auf alle Arten von möglichen Eingabewerten sind in der Spezifikation definiert Für weitere Definitionen syntaktischer Natur siehe [Davis] Wichtig: Vollständigkeit einer Anforderungsspezifikation ist ein anderes Kozept als die Vollständigkeit einer Spezifikationssprache (z.B. Logik) verifzierbar (verifiable) Es existiert eine effektive Prozedur durch die entweder manuell oder mit maschineller Unterstützung überprüft werden kann, ob ein Softwareprodukt die in der Spezifikation geforderten Eigenschaften erfüllt. Beispiele: formale Verifikation, model checking, Testen Viele Anforderungen sind nicht verifizierbar: “Nach jeden eingegebenen Befehl soll das Betriebssystem die Kontrolle wieder an den Benutzer übergeben” “Die Software soll nie in eine unendliche Schleife eintreten.” “Die Benutzerschnittstelle soll einfach zu bedienen sein.” Entwurf von Telekommunikationssystemen

48 Eigenschaften von Anforderungsspezifikationen
konsitent (consistent) keine zwei Anforderungen stehen im logischen Widerspruch mögliche Inkonsistenzen: widersprüchliches Verhalten Wenn der Hörere aufgenommen wird, ertönt ein Wählton Wenn der Hörer aufgenommen wird, ertönt ein Klingelton widersprüchliche Ausdrücke widersprüchliche Eigenschaften Zeitliche Inkonsistenzen Eingabe a führt zur zeitgleichen Ausgabe b Ein Ereignis b darf nie früher beobachtet werden als 15 Sekunden nach einem Ereignis a Entwurf von Telekommunikationssystemen

49 Eigenschaften von Anforderungsspezifikationen
nachvollzogen (traced) Der Ursprung und der Grund für jede Anforderung sind klar z. B., Dokumentation, warum gewisse Werte (z.B. für Zeitschranken) gewählt worden sind nachvollziehbar (traceable) Die Anforderungsspezifikation ist so geschrieben, dass es einfach ist, jede einzige Anforderung isoliert zu benennen Oft: eindeutiges Numerierungsschema Wichtig für das Testen von Software entwurfsunabhängig (design independent) Die Anforderungsspezifikation verlangt keine spezielle Softwarearchitektur und schreibt keine algorithmische Implementierung vor Andernfalls handelt es sich um eine Überspezifikation Entwurf von Telekommunikationssystemen

50 Klassifikation von Softwaresystemen
Transformationssysteme (transformational) transfomieren eine (möglicherweise leere) Menge an Eingabedaten in Ausgabedaten beschreiben eine Funktion von einem Initialzustand Si in einen Endzustand Sj Prädikatenlogik höherer Stufe kann normalerweise verwendet werden, um die Transformation zu beschreiben (z.B. unter Verwendung von Hoare-Triples) Anwendungsbeispiele numerische Berechnungen in Natur- und Ingenieurswissenschaften Compiler Datenbank Batch-Anwendungen (z.B. Gehaltsabrechnungen) Korrektheit Terminierung Korrektheit der Abbildung Si  Sj Korrektheit der Eingabe-Ausgabebeziehung Entwurf von Telekommunikationssystemen

51 Klassifikation von Softwaresystemen
Reaktive Systeme (reactive) unterhalten eine fortwährende Interaktion mit der Umgebung von Ereignissen in der Umgebung getrieben reagieren fortwährend auf stimulierende Ereignisse Beispiele Betriebssysteme Interpretatoren Kommunikationsprotokolle Prozesskontrollsysteme Korrektheit meistens Nichtterminierung Korrektheit der Reaktion auf ein Ereignis Beschreibung durch Modelle, die andauernde Ein- und Ausgabefolgen zu beschreiben in der Lage sind (Zustands-Transitionssysteme, Logiken) Entwurf von Telekommunikationssystemen

52 Klassifikation von Softwaresystemen
Eingebettete Systeme (embedded) gewöhnlich reaktive Systeme, die eng mit Hardwaresystemen verbunden sind und deren Funktion kontrollieren werden oft in dedizierter Hardware ausgeführt die Grenze zwischen Soft- und Hardware verwischt sich gelegentlich Beispiele Autopiloten im Flugzeug Steuerungsprozessoren im Automobil Zeitsteuerung in der Mikrowelle Kontrollsoftware in digitaler Telefonanlage (PBX) Korrektheitskriterien und Beschreibungsmethoden wie bei reaktiven Systemen Entwurf von Telekommunikationssystemen

53 Klassifikation von Softwaresystemen
Echtzeitsysteme (real-time) bisher: Korrektheit hängt nicht von der relativen oder absoluten Geschwindigkeit der Rechenvorgänge der beteiligten Systemkomponenten ab z.B., “drücken des Anforderungsknopfes führt irgendwann später zum Eintreffen des Fahrstuhls” kein besonders nützliches Konzept wenn die Zeitspanne zwischen Anforderung und Ankunft die menschliche Lebenserwartung übersteigt… daher enthalten Systemspezifikationen oft Echtzeitschranken “drücken des Anforderungsknopfes führt innerhalb von höchstens 10 Minuten zum Eintreffen des Fahrstuhls” Unterscheidung weiche Echtzeitsysteme harte Echtzeitsysteme siehe Kapitel 1 aus [Heitmeyer und Mandrioli] Entwurf von Telekommunikationssystemen

54 Klassifikation von Softwaresystemen
weiche Echtzeitsysteme es werden Zeitschranken für das System festgelegt, aber eine Verletzung dieser Schranken führt nicht zu einer Verletzung des Systemzwecks (Unter- oder Überschreitung kann toleriert werden) gewöhnlich werden Wahrscheinlichkeiten für die Verletzung oder Erfüllung der Zeitschranken spezifiziert, z. B.: mit einer Wahrscheinlichkeit von mindestens 0.99 erfolgt auf das Abnehmen des Hörers innerhalb von 500 ms ein Wählton oder ein Bestztzeichen dies Arten von Anforderungen werden auch als Dienstgüteanforderungen (quality of service requirements) bezeichnet, speziell im Kontext von Rechnernetzen (z.B. delay jitter in ATM Netzen) Spezifikation: Zeitmodelle, um stochastische Komponenten erweitert (z.B. zeitbehaftete Markovketten) Korrektheit: Erfüllung des stochastischen und des Zeitmodells Achtung: “Echtzeitsysteme” wird gelegentlich synonym verwendet mit “reaktiven Systemen”, “eingebetteten Systemen” oder “weichen Echtzeitsystemen” Entwurf von Telekommunikationssystemen

55 Klassifikation von Softwaresystemen
harte Echtzeitsysteme Die Korrektheit des Systems hängt von der Einhaltung der Echtzeitbedingungen ab Das System muss innerhalb von 20 Sekunden nach dem einrasten des Fahrwerks die Fahrwerksluke geschlossen haben Anforderung an ein Sicherheitssystem für einen Reaktorkern: Das System überwacht den Wasserdruck und muss innerhalb von 30 Sekunden zusätzliches Kühlmittel in den Reaktorkern pumpen falls der Wasserdruck unter einen Grenzwert V gefallen ist. Typische Formen von Echtzeitanforderungen: Maximal- und minimalwerte zwischen Stimulus / Antwort Antwort / Antwort Stimulus / Stimulus Antwort / Stimulus Spezifikation: Echtzeit-erweiterte Modelle (Automaten, temporale Logiken, etc) Entwurf von Telekommunikationssystemen

56 Klassifikation von Softwaresystemen
Hybride Systeme (hybrid) dynamische Systeme, die sowohl durch diskrete wie auch durch kontinuierliche Variablen gekennzeichnet werden. Beispiel: Thermostat oder chemischer, gesteuerter Prozess Beispiel: Kontrollsystem für Bahnübergang diskrete Variablen Öffnungszustand der Schranke Zug im Übergang kontinuierliche Variablen Geschwindigkeit des Zuges Beschleunigung des Zuges Zeitpunkte des öffnens/schliessen Anforderungen: Es darf sich nie ein Zug im Durchgangsbereich befinden wenn die Schranke nicht geschlossen ist. Spezifikation durch hybride Erweiterungen von diskreten Modellen Entwurf von Telekommunikationssystemen

57 Fokussierung für diese Vorlesung
Reaktive Systeme, ohne Zeitaspekt, diskret Nebenläufige Systeme mit Synchronisation durch Nachrichtenaustausch oder gemeinsamen Speicher Entwurf von Telekommunikationssystemen

58 Fokussierung für diese Vorlesung
Methoden zur Beschreibung und Validation von Anforderungen, speziell während der frühen Phasen des Entwurfsprozesses Kunden- oder Be- nutzeranforderungen (abstrakt) Anforderungs- analyse und Vereinbarung Anforderungs- dokumentation und Spezifikation Validation Anforderungs- ermittlung Vereinbarte und Validierte Anforderungen Entwurf von Telekommunikationssystemen

59 Bibliographische Referenzen
[Davis] A. M. Davis, Software Requirements - Objects, Functions and States, Prentice-Hall, 1993 [Heimeyer und Mandrioli] C. Heitmeyer and D. Mandrioli, Formal Methods for Real-Time Computing, Wiley, 1996 [Kotonya and Sommerville] A. Kotonya and I. Sommerville, Requirements Engineering, Wiley, 1997 [Pfleeger] S. L. Pfleeger, Software Engineering - Theory and Practice, Prentice-Hall, 1998 [Rushby] J. Rushby, Formal Methods and the Certification of Critical Systems, Technical Report CSL-93-7, Computer Science Lab, SRI International, December 1993 Entwurf von Telekommunikationssystemen