Traditionelle „strukturierte“ Spezifikationsmethoden

Transcription

Traditionelle „strukturierte“ Spezifikationsmethoden
Traditionelle „strukturierte“ Spezifikationsmethoden
Bekannte Ansätze
✩
Datenmodellierung (Entity-Relationship-Modelle)
✩
Strukturierte Analyse
✩
"Moderne Strukturierte" Analyse, SA/RT
✩
SADT
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
1
Datenmodellierung
❏
Grundlage: Entity-Relationship Ansatz (Chen 1976)
❏
modelliert einen Ausschnitt der Realität mit Hilfe von Gegenstandstypen (entity types),
Beziehungstypen (relationship types) und Attributen (attributes)
arbeitet in
Person
Abteilung
ist beteiligt an
Projekt
+
+
Einfach und klar
Leicht auf Datenbank-Realisierungen abbildbar
–
–
–
–
Ignoriert Funktionalität und Verhalten der Systeme
Keine Mittel zur Systemdekomposition
Keine Lokalität oder Einkapselung von Daten
Kümmert sich nicht um Wiederverwendung
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
2
Strukturierte Analyse
✩
Modelliert die Funktionalität eines Systems mit Hilfe von Datenflussdiagrammen
(DeMarco 1978, Gane und Sarson 1979)
Anzeige
Rohwert
Grenzwerte
Messwert
dimensionieren
Messwert
Dimension
Messwert
Grenzwerte
prüfen
AlarmIndikator
Instrumentanzeige aufbauen
InstrumentBilder
❍
Teilformale, konstruktive Spezifikationsmethode
❍
Basiert auf dem Prinzip der datengesteuerten Verarbeitung: Jede Aktivität arbeitet
dann, wenn die von ihr benötigten Daten eintreffen
❍
Datenflussdiagramme sind hierarchisch strukturiert
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
3
Grundkonzepte
der Strukturierten
Analyse
DatenflußDiagramm(e)
Gast :=
Name + Vorname +
Adresse
Name :=
{Zeichen}
...
Datenlexikon
SA
Zimmer
reservieren
WENN
Zimmer der gewünschten Art
ist frei
DANN...
.....
MiniSpezifikationen
Dekomposition
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
4
Notation für Datenflussdiagramme (links: DeMarco, rechts: Gane und Sarson)
Aktivität (Prozess; activity, process)
Datenfluss (dataflow)
Speicher (store, file)
Endknoten (terminator, terminal, external)
Interpretation von Datenflussdiagrammen
❏
Datenflüsse transportieren Datenpakete, die von Aktivitäten oder Endknoten produziert
bzw. konsumiert werden.
❏
Aktivitäten arbeiten nur dann, wenn alle von ihnen benötigten Eingabe-Datenflüsse
vorliegen. Die Aktivität konsumiert die Daten, bearbeitet sie und produziert AusgabeDatenflüsse. Sie kann dabei zusätzlich Speicherinhalte lesen oder schreiben.
❏
Speicher modellieren Datenbehälter. Ihr Inhalt kann gelesen werden (ohne den
Speicher zu verändern) und geschrieben werden (dabei wird der alte Inhalt zerstört).
❏
Endknoten sind Aktivitäten in der Systemumgebung.
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
5
❍
Datenflussdiagramme sind Übersichtsmodelle
❍
Zur Präzisierung müssen definiert werden:
❍
die Namen aller Datenflüsse und Speicher ->Datenlexikon
❍
die Funktionalität jeder nicht hierarchisch zerlegten Aktivität -> Mini-Spezifikationen
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
6
Das Datenlexikon
Definiert alle im Modell verwendeten Datennamen
❍
Gebräuchliche Notation:
a = expr (oder a := expr)
"<zeichenfolge>"
Stelle
a wird durch den Ausdruck expr definiert
Literal. <zeichenfolge> muss wörtlich an der betreffenden
vorkommen
*<text>*
<text> ist ein Text, der als informale Definition oder als
Erläuterung dient
❍
Elementardefinitionen: Ein Datum wird durch einen Text oder ein Literal definiert
❍
Strukturdefinitionen:
c=a+b
c=[a|b]
c = n{a}m
c = {a}
c = (a)
c ist zusammengesetzt aus a und b
c ist entweder a oder b
c ist eine n- bis m-fache Wiederholung von a
äquivalent mit 0{a}∞
äquivalent mit 0{a}1, (d.h. a ist optional)
a, b, c: Namen oder Elementardefinitionen
❍
Eine Definition kann zusätzlich durch Texte annotiert werden
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
7
Beispiele
Reservierungswunsch :=
Anzahl + Zimmerart + ResVon + ResBis + Name
*erwartete Angaben für eine Reservation*.
Anzahl :=
* 1..N *
*Anzahl der bestellten Zimmer*.
Zimmerart :=
[ "EZ" | "DZ" | "EZmitDuWC" | "DZmitDuWC" ]
*Art der bestellten Zimmer *.
Name :=
{Zeichenkette}
*Name des Gasts, für den reserviert wird*.
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
8
Mini-Spezifikationen
❍
Elementare, nicht weiter zerlegte Spezifikation einer Aktivität
❍
Beschreibt den geforderten Zusammenhang zwischen den Eingabe- und den
Ausgabedaten einer Aktivität
❍
Mögliche Darstellungsformen
❍
❍
Informale Beschreibung mit Text
❍
Pseudocode
❍
Formale Ergebnisbeschreibung mit mathematischen Formeln
❍
Teilformale Ergebnisbeschreibung (kein Ablauf, nur geforderte Resultate)
❍
Entscheidungstabellen
Wahl der Darstellungsform je nach Problemstellung
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
9
Hierarchische Zerlegung
❍
Eine Aktivität kann wiederum durch ein Datenflussdiagramm beschrieben werden ->
DFD-Hierarchie
❍
Ebenen müssen konsistent (balanciert) sein
❍
An der Spitze der Hierarachie steht ein Kontextdiagramm
Kontext-Diagramm
0
DFD 0
3
2
1
DFD 1
.2
DFD 3
.3
.3
.2
.4
.1
.1
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
10
Methodik der Modellierung
Essentielle Systemanalyse (McMenamin und Palmer 1984)
Klassisches Vorgehen:
1
Erstelle ein Kontextdiagramm
2
Erstelle eine Ereignisliste (Ereignis = Anstoß aus der Außenwelt, der eine Reaktion
des Systems erfordert)
3
❏
❏
❏
❏
Zeichne ein DFD mit einer Aktivität für jeden Vorgang (Vorgang = Verarbeitung
eines Ereignisses und Erzeugung der erwarteten Reaktionen)
Schließe interaktiv die dabei auftretenden Informationslücken
Definiere die verwendeten Daten
Skizziere Mini-Spezifikationen
4
Restrukturiere dieses (in der Regel sehr große) DFD in eine Hierarchie
5
Vervollständige das Modell
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
11
Problem: ergibt große, schwach strukturierte DFD, keine Lokalität oder Kapselung möglich
➬
besseres Vorgehen:
2'
❏
❏
❏
Gliedere die Aufgabe in Teile, die (soweit wie möglich) in sich geschlossen sind
Erstelle die Ereignisliste
Bilde Unter-Ereignislisten für jede Teilaufgabe
3'
Arbeite gemäß 3 für jede Teilaufgabe; stimme dabei das Neue auf schon vorhandene
Teilmodelle ab
4'
Arbeite gemäß 4 für jede Teilaufgabe (falls nötig)
5'
Arbeite gemäß 5 und synthetisiere die oberste(n) Zerlegungsebene(n) aus den TeilModellen
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
12
Schwächen der „reinen“ Strukturierten Analyse
✩
Zusammenhänge zwischen Datenspeichern nicht modellierbar
➥
Verbindung mit Entity-Relationship-Diagrammen (Chen 1976)
❍
Jeder Speicher ist Gegenstandstyp eines Entity-Relationship-Diagramms
✩
Zeit- und zustandsabhängiges Verhalten nicht modellierbar
➥
Verbindung mit Zustandsautomaten
(meistens SA/RT genannt, RT steht für Real Time; Hatley und Pirbhai 1988, Ward und
Mellor 1985)
➔
❍
Zwei zusätzliche Modell-Elemente:
– Steuerflüsse (gestrichelter Pfeil im DFD)
– Steuerspezifikationen (fette Linie oder gestrichelter Kreis im DFD)
❍
Steuerspezifikationen beschreiben das dynamische Verhalten mit Zustandsautomaten und die zugehörigen Aktivitäten im DFD mit Aktivierungstabellen
❍
Steuerflüsse transportieren die Ereignisse, welche die Zustandsautomaten steuern
oder dort erzeugt werden
Sogenannte Moderne Strukturierte Analyse oder SA mit Erweiterungen (Yourdon 1989)
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
13
Stärken und Schwächen der Strukturierten Analyse
(u.a. Glinz 1991)
+ Sehr anschaulich
+ Datenfluss ist ein natürliches Operationsprinzip für viele Probleme
+ Unterstützt Systemdekomposition
–
Strukturbruch zwischen Spezifikation und Implementierung
–
Keine Lokalität von Daten; Einkapselung nur begrenzt möglich
–
keine integrierte Modellierung von Daten, Funktionen und zeitlichem Verhalten;
stattdessen Patchwork von Datenfluss-, Entity-Relationship- und Zustandsdiagrammen
–
Mittel zur Datendefinition umständlich und veraltet
–
Einbettung in vorhandene Software nur schwer modellierbar
✩
(Erweiterte) Strukturierte Analyse war das Verfahren der 80er Jahre
✩
Wird langsam aber sicher durch objektorientierte Verfahren verdrängt
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
14
SADT
SADT: Structured Analysis and Design Technique (Ross, 1977)
≠
Strukturierte Analyse (Structured Analysis nach DeMarco, Gane und Sarson,
McMenamin und Palmer, etc.)
✩
Zwei Diagrammtypen
✧
Aktivitätsdiagramme
✧
Datendiagramme
✩
Hierarchische Zerlegung
✩
Wird praktisch nicht mehr verwendet
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
15
Aktivitätsdiagramme
❍
Aktivitäten sind die zentralen Modellelemente
❍
Aktivitäten durch Datenflüsse verbunden/angestoßen -> Ähnlich wie
Datenflussdiagramme
❍
Zusätzlich werden Steuerflüsse und Mechanismen modelliert
❍
Datenfluss streng von links nach rechts
Steuerdaten
Eingabedaten
Ausgabedaten
Aktivität
Ressourcen,
Mechanismen
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
16
Datendiagramme
❍
Daten sind die zentralen Modellelemente
❍
Flüsse modellieren primär Erzeugung und Verwendung von Daten
❍
Ferner werden Steuerinformationen und Speichermedien modelliert
Steuernde Aktivität(en)
Erzeugende
Aktivität(en)
Verwendende
Aktivität(en)
Datum
Speichermedium
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
17
Literatur
Chen, P.P. (1976) The Entity-Relationship Model -Toward a Unified View of Data. ACM Transactions on Database
Systems 1, 1 (March 1976). 9-36.
DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press, New York.
Gane C., T. Sarson (1979). Structured Systems Analysis: Tools and Techniques. Prentice-Hall, Englewood Cliffs,
N.J.
Glinz, M. (1991). Probleme und Schwachstellen der Strukturierten Analyse. In Timm, M. (Hrsg.): Requirements
Engineering '91. Informatik-Fachberichte Band 273, Berlin, etc.: Springer. 14-39.
Hatley, D.J., I.A. Pirbhai (1988). Strategies for Real-Time System Specification. Dorset House, New York.
McMenamin, S.M., J.F. Palmer (1984). Essential Systems Analysis. Yourdon Press, New York.
Ross, D. (1977). Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software
Engineering, SE-3, 1 (Jan. 1977). 16-34.
Ward, P.T., S.J. Mellor (1985). Structured Development for Real-Time Systems, Vol. I-III. Prentice-Hall, Englewood
Cliffs, N.J.
Yourdon, E. (1989). Modern Structured Analysis. Prentice-Hall, Englewood Cliffs, N.J. 672 p.
Requirements Engineering: Strukturierte Spezifikationsmethoden
M. Glinz
WS 2000/01
18