Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg

Ähnliche Präsentationen


Präsentation zum Thema: "Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg"—  Präsentation transkript:

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

2 tele Entwurf von Telekommunikationssystemen- 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

3 tele 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

4 tele 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

5 tele 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

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

7 tele Entwurf von Telekommunikationssystemen- 7 - Softwarekrise?  Standish Group (http://www.standishgroup.com, nach [Pfleeger]),http://www.standishgroup.com  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

8 tele 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

9 tele Entwurf von Telekommunikationssystemen- 9 - Softwarekrise - Historisch

10 tele Entwurf von Telekommunikationssystemen Softwarekrise - Historisch

11 tele Entwurf von Telekommunikationssystemen Softwarekrise - Historisch

12 tele Entwurf von Telekommunikationssystemen Softwarekrise - Historisch

13 tele Entwurf von Telekommunikationssystemen Softwarekrise - Historisch

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

15 tele Entwurf von Telekommunikationssystemen 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

16 tele Entwurf von Telekommunikationssystemen 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”

17 tele Entwurf von Telekommunikationssystemen 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

18 tele Entwurf von Telekommunikationssystemen Software Engineering  Konsequenz  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

19 tele Entwurf von Telekommunikationssystemen Life-cycle Model: Waterfall

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

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

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

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

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

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

26 tele Entwurf von Telekommunikationssystemen Modifiziertes Wasserfallmodell

27 tele Entwurf von Telekommunikationssystemen Zeit/Resourcen pro Stufe

28 tele Entwurf von Telekommunikationssystemen Zeit/Resourcen pro Stufe

29 tele Entwurf von Telekommunikationssystemen 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.”

30 tele Entwurf von Telekommunikationssystemen 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

31 tele Entwurf von Telekommunikationssystemen 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 Spezifikation Korrekter Entwurf korrekte Funktionalität korrektes Programm fehlerhafter Entwurf Programmier- fehler korrigierbare Fehler Programm bas. auf fehlerh. Spezifikation Entwurf bas. auf fehlerh. Spezifikation Programm bas. auf fehlerh. Entwurf nicht korrigierbare Fehler nicht erkennbare Fehler Entwurf Implementierung Testen Anwendungsproblem Spezifikation

32 tele Entwurf von Telekommunikationssystemen 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

33 tele Entwurf von Telekommunikationssystemen 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

34 tele Entwurf von Telekommunikationssystemen 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

35 tele Entwurf von Telekommunikationssystemen 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

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

37 tele Entwurf von Telekommunikationssystemen 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.”

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

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

40 tele Entwurf von Telekommunikationssystemen 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

41 tele Entwurf von Telekommunikationssystemen  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 Sprachen für Anforderungsspezifikationen

42 tele Entwurf von Telekommunikationssystemen  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 Sprachen für Anforderungsspezifikationen

43 tele Entwurf von Telekommunikationssystemen  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 Sprachen für Anforderungsspezifikationen

44 tele Entwurf von Telekommunikationssystemen 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.

45 tele Entwurf von Telekommunikationssystemen 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

46 tele Entwurf von Telekommunikationssystemen 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”)

47 tele Entwurf von Telekommunikationssystemen 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.”

48 tele Entwurf von Telekommunikationssystemen 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

49 tele Entwurf von Telekommunikationssystemen 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

50 tele Entwurf von Telekommunikationssystemen Klassifikation von Softwaresystemen  Transformationssysteme (transformational)  transfomieren eine (möglicherweise leere) Menge an Eingabedaten in Ausgabedaten  beschreiben eine Funktion von einem Initialzustand S i in einen Endzustand S j  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 S i  S j –Korrektheit der Eingabe-Ausgabebeziehung

51 tele Entwurf von Telekommunikationssystemen 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)

52 tele Entwurf von Telekommunikationssystemen 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

53 tele Entwurf von Telekommunikationssystemen 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]

54 tele Entwurf von Telekommunikationssystemen 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”

55 tele Entwurf von Telekommunikationssystemen 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)

56 tele Entwurf von Telekommunikationssystemen 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

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

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

59 tele Entwurf von Telekommunikationssystemen 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


Herunterladen ppt "Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg"

Ähnliche Präsentationen


Google-Anzeigen