Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg [email protected] leue

tele

Entwicklung von Telekommunikationssystemen

Prof. Dr. Stefan LeueAlbert-Ludwigs-Universität Freiburg

[email protected]

http://www.informatik.uni-freiburg.de/~leue

Sommersemester 2000

Copyright © Stefan Leue 2000

Entwurf von Telekommunikationssystemen - 2 -

tele

Ü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


tele

Ü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


tele

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


tele

Relevanz von Software

Telekommunikationssysteme bestehen aus Hardware und Software Software bestimmt etwa 60-80% des Entwicklungsaufwands

Beispiele Nortel Networks, DMS-100 Vermittlungsanlage

– c.a. 25-30 Mio Codezeilen– Lebenszyklus: Entwicklung seit 1981– c.a. 2000-3000 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 10000 Zeilen Code


tele

Softwarekrise?

Studie des US Government Accounting Office - 1979

never delivered

29%

never used47%

reworked/abandoned

19%

used as delivered

2%

used after changes

3%

9 contracts, total $7 mio


tele

Softwarekrise? Standish Group (http://www.standishgroup.com , 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


tele

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


tele

Softwarekrise - Historisch


tele



tele



tele



tele



tele

Symptome der Softwarekrise

Softwareprojekte überschreiten geplante Zeit- und Budgetgrenzen

Softwareprojekte werden vorzeitig abgebrochen

Softwareprodukte beinhalten nicht die gewünschte Funktionalität

Softwareprodukte sind fehlerbehaftet


tele

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


tele

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”


tele

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


tele

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


tele

Life-cycle Model: Waterfall


tele


System Design• overall design• HW/SW split• informal, with cusotmer

System design


tele


System design SW Requirements• “what” the system has to do• functional/non-functional• observable behaviour• SRS document

RequirementsSRS


tele


System design Design• “how” the system is doing it• architectural design • detailed design• design document

RequirementsSRS

Design

Design


tele


System design

Module Implementation and Test• implement module structure• test modules in isolation

RequirementsSRS

Design

Design

Implementation


tele


System design Integration• integrate modules• integration testing • customer acceptance tests

RequirementsSRS

Design

Design

Implementation

Integration


tele


System designMaintenance

• deploy product• corrective, adaptive,

perfective maintenance

RequirementsSRS

Design

Design

Implementation

Integration

Maintenance


tele

Modifiziertes Wasserfallmodell


tele

Zeit/Resourcen pro Stufe


tele

Zeit/Resourcen pro Stufe


tele

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 30-35000 ausgelieferten Quellcodeinstruktionen– 10% der Fehler beruhen auf Anforderungsfehlern und 55% auf

Entwurfsfehlern für Projekte mit einer Grösse von 40-80000 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.”


tele

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

1 5 1020

50

200

020406080

100120140160180200Unit cost

Req

uir

emen

ts

Des

ign

Imp

lem

ent.

Mo

du

le t

est

Inte

gra

tio

n

Mai

nte

nan

ce


tele

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:

korrekteSpezifikation

fehlerhafteSpezifikation

KorrekterEntwurf

korrekteFunktionalität

korrektesProgramm

fehlerhafterEntwurf

Programmier-fehler

korrigierbareFehler

Programm bas.auf fehlerh.Spezifikation

Entwurf bas.auf fehlerh.Spezifikation

Programm bas.auf fehlerh.Entwurf

nichtkorrigierbareFehler

nichterkennbareFehler

Entwurf

Implementierung

Testen

Anwendungsproblem

Spezifikation


tele

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


tele

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


tele

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


tele

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


tele

Grobes Prozessmodell für die Anforderungsphase

Anforderungs-analyse und Vereinbarung

Anforderungs-dokumentation

und SpezifikationValidation

Kunden- oder Be-

nutzeranforderungen

(abstrakt)

Anforderungs-

ermittlung

Vereinbarte undValidierte

Anforderungen


tele

Anforderungen Anforderungsspezifikation (auch Pflichtenheft oder

Lastenheft genannt) ist häufig die Basis einer vertraglichen Vereinbarung zwischen Softwareersteller und dem Kunden

Nach ANSI/IEEE Standard 729-1983 “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.”


tele

Was / Wie Dilemma

Copyright © Prentice-Hall Inc., 1993 1990


tele

Anforderungsspezifikation

Vollständige Beschreibung des extern sichtbaren Verhaltens

System

Schnittstelle

Umgebung


tele

Struktur einer Anforderungsspezifikation

Unterschiedliche, teils standardisierte Schablonen

Beispiel: ANSI/IEEE STD-830-1984 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


tele

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

))()()(|,( 212121 tdialtonetringtonetttt


tele

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



tele

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



tele

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.


tele


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


tele


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”)

)))()(()((

)(),()(,(

XRingBXBRing

BIdleBACallBA


tele


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.”


tele


konsitent (consistent) keine zwei Anforderungen stehen im logischen Widerspruch mögliche Inkonsistenzen:

– widersprüchliches VerhaltenWenn der Hörere aufgenommen wird, ertönt ein WähltonWenn 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


tele


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


tele

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


tele

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)


tele

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


tele

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]


tele

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”


tele

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)


tele

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


tele

Fokussierung für diese Vorlesung

Reaktive Systeme, ohne Zeitaspekt, diskret

Nebenläufige Systeme mit Synchronisation durch Nachrichtenaustausch oder gemeinsamen Speicher


tele

Anforderungs-analyse und Vereinbarung

Anforderungs-dokumentation

und SpezifikationValidation

Kunden- oder Be-

nutzeranforderungen

(abstrakt)

Anforderungs-

ermittlung

Vereinbarte undValidierte

Anforderungen

Fokussierung für diese Vorlesung

Methoden zur Beschreibung und Validation von Anforderungen, speziell während der frühen Phasen des Entwurfsprozesses


tele

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

Documents

Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität Freiburg [email protected] leue