Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität...
-
Upload
filabert-gernert -
Category
Documents
-
view
107 -
download
1
Transcript of Tele Entwicklung von Telekommunikationssystemen Prof. Dr. Stefan Leue Albert-Ludwigs-Universität...
tele
Entwicklung von Telekommunikationssystemen
Prof. Dr. Stefan LeueAlbert-Ludwigs-Universität Freiburg
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
Entwurf von Telekommunikationssystemen - 3 -
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
Entwurf von Telekommunikationssystemen - 4 -
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
Entwurf von Telekommunikationssystemen - 5 -
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
Entwurf von Telekommunikationssystemen - 6 -
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
Entwurf von Telekommunikationssystemen - 7 -
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
Entwurf von Telekommunikationssystemen - 8 -
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
Entwurf von Telekommunikationssystemen - 9 -
tele
Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen - 10 -
tele
Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen - 11 -
tele
Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen - 12 -
tele
Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen - 13 -
tele
Softwarekrise - Historisch
Entwurf von Telekommunikationssystemen - 14 -
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
Entwurf von Telekommunikationssystemen - 15 -
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
Entwurf von Telekommunikationssystemen - 16 -
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”
Entwurf von Telekommunikationssystemen - 17 -
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
Entwurf von Telekommunikationssystemen - 18 -
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
Entwurf von Telekommunikationssystemen - 19 -
tele
Life-cycle Model: Waterfall
Entwurf von Telekommunikationssystemen - 20 -
tele
Life-cycle Model: Waterfall
System Design• overall design• HW/SW split• informal, with cusotmer
System design
Entwurf von Telekommunikationssystemen - 21 -
tele
Life-cycle Model: Waterfall
System design SW Requirements• “what” the system has to do• functional/non-functional• observable behaviour• SRS document
RequirementsSRS
Entwurf von Telekommunikationssystemen - 22 -
tele
Life-cycle Model: Waterfall
System design Design• “how” the system is doing it• architectural design • detailed design• design document
RequirementsSRS
Design
Design
Entwurf von Telekommunikationssystemen - 23 -
tele
Life-cycle Model: Waterfall
System design
Module Implementation and Test• implement module structure• test modules in isolation
RequirementsSRS
Design
Design
Implementation
Entwurf von Telekommunikationssystemen - 24 -
tele
Life-cycle Model: Waterfall
System design Integration• integrate modules• integration testing • customer acceptance tests
RequirementsSRS
Design
Design
Implementation
Integration
Entwurf von Telekommunikationssystemen - 25 -
tele
Life-cycle Model: Waterfall
System designMaintenance
• deploy product• corrective, adaptive,
perfective maintenance
RequirementsSRS
Design
Design
Implementation
Integration
Maintenance
Entwurf von Telekommunikationssystemen - 26 -
tele
Modifiziertes Wasserfallmodell
Entwurf von Telekommunikationssystemen - 27 -
tele
Zeit/Resourcen pro Stufe
Entwurf von Telekommunikationssystemen - 28 -
tele
Zeit/Resourcen pro Stufe
Entwurf von Telekommunikationssystemen - 29 -
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.”
Entwurf von Telekommunikationssystemen - 30 -
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
Entwurf von Telekommunikationssystemen - 31 -
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
Entwurf von Telekommunikationssystemen - 32 -
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
Entwurf von Telekommunikationssystemen - 33 -
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
Entwurf von Telekommunikationssystemen - 34 -
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
Entwurf von Telekommunikationssystemen - 35 -
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
Entwurf von Telekommunikationssystemen - 36 -
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
Entwurf von Telekommunikationssystemen - 37 -
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.”
Entwurf von Telekommunikationssystemen - 38 -
tele
Was / Wie Dilemma
Copyright © Prentice-Hall Inc., 1993 1990
Entwurf von Telekommunikationssystemen - 39 -
tele
Anforderungsspezifikation
Vollständige Beschreibung des extern sichtbaren Verhaltens
System
Schnittstelle
Umgebung
Entwurf von Telekommunikationssystemen - 40 -
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
Entwurf von Telekommunikationssystemen - 41 -
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
Entwurf von Telekommunikationssystemen - 42 -
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
Sprachen für Anforderungsspezifikationen
Entwurf von Telekommunikationssystemen - 43 -
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
Sprachen für Anforderungsspezifikationen
Entwurf von Telekommunikationssystemen - 44 -
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.
Entwurf von Telekommunikationssystemen - 45 -
tele
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 -
tele
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”)
)))()(()((
)(),()(,(
XRingBXBRing
BIdleBACallBA
Entwurf von Telekommunikationssystemen - 47 -
tele
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 -
tele
Eigenschaften von Anforderungsspezifikationen
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
Entwurf von Telekommunikationssystemen - 49 -
tele
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 -
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
Entwurf von Telekommunikationssystemen - 51 -
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)
Entwurf von Telekommunikationssystemen - 52 -
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
Entwurf von Telekommunikationssystemen - 53 -
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]
Entwurf von Telekommunikationssystemen - 54 -
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”
Entwurf von Telekommunikationssystemen - 55 -
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)
Entwurf von Telekommunikationssystemen - 56 -
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
Entwurf von Telekommunikationssystemen - 57 -
tele
Fokussierung für diese Vorlesung
Reaktive Systeme, ohne Zeitaspekt, diskret
Nebenläufige Systeme mit Synchronisation durch Nachrichtenaustausch oder gemeinsamen Speicher
Entwurf von Telekommunikationssystemen - 58 -
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
Entwurf von Telekommunikationssystemen - 59 -
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