- Lehrstuhl für Betriebliche Informationssysteme

Transcription

Institut für Informatik
Betriebliche Informationssysteme
Vorlesung Softwaretechnik
- Strukturierte Analyse / Real Time Analysis Prof. Dr.-Ing. habil. Klaus-Peter Fähnrich
Wintersemester 2009/2010
Prof. K.-P. Fähnrich (nach Balzert)
Vorlesung: 9
Seite
1 1
SWT – SA/RT
Überblick LE 14
LE 14: Strukturierte Analyse
•
•
•
•
•
•
•
•
Das Hierarchiekonzept
Das Kontextdiagramm
Verfeinerte
e e e te DFD
Data Dictionary -Einträge und Datenintegrität
Mini-Spezifikation
M th dik
Methodik
Qualitätssicherung
Wertung
LE 15: Strukturierte Analyse/Real Time Analysis
Vorlesung: 9
Seite 2
SWT – SA/RT
Lernziele
1.
2.
3
3.
4.
Vor- und Nachteile der strukturierten Analyse
Basiskonzepte und ihre Kombination in SA
Zusammenhang zu ER-Modellen
ER Modellen und Funktionsbäumen
Erstellen eines vollständigen SA-Modell für eine gegebene
Problemstellung
5 Einzuhaltende Regeln und methodische Schritte bei der
5.
Erstellung eines SA-Modells
Vorlesung: 9
Seite 3
SWT – SA/RT
Definition
• Die Strukturierte Analyse (SA) :
 Beschreibt eine Methodenklasse
 Wichtige
c t ge SA-Varianten:
S
a a te
°
°
°
°
Weinberg 1978: »Structured Analysis«
Gane/Sarson 1979: »Structured Systems Analysis«
McMenamin/Palmer 1984: »Essential Systems Analysis«
Yourdon 1989: »Modern Structured Analysis«
 SA ist Stand der Technik und Industriestandard
 SA nach DeMarco wird hier vorgestellt.
Vorlesung: 9
Seite 4
SWT – SA/RT
Kombination von Basiskonzepten SA
SA SA
(1979)
ET ((Entscheidungsg
tabelle)
Entscheidungsbäume
Funktionsu to s
baum
Datenflussate uss
diagramm
Data
ata
Dictionary
Funktionale
Hierarchie
Informationsfluss
Datenstrukturen
Legende:
A
A
Pseudo-Code
Kontrollstrukturen
B: A ist in B enthalten
B: A ist implizit in B enthalten
Vorlesung: 9
Seite 5
SWT – SA/RT
Aufbau
• Hierarchisierung zur Steigerung der Übersichtlichkeit
• Datenflussdiagramme (DFD) werden hierarchisch verfeinert
• Kontextdiagramm steht als abstraktes DFD in der obersten
Hierarchieebene.
• Jeder Prozess wird in untergeordneten Diagrammen verfeinert.
• Ist keine Verfeinerung mehr möglich, wird eine textuelle
Mini-Spezifikation erstellt.
Vorlesung: 9
Seite 6
SWT – SA/RT
Hierarchiekonzept
• Kontextdiagramm
• Diagramm
ag a
0
• Diagramm 3
• MiniSpec 3.1
31
DD :
A = a 1 + (a 2 )
B = [b 1 | b 2 ]
a2 = x + y
Vorlesung: 9
Seite 7
SWT – SA/RT
Kontextdiagramm - Syntaxregeln
• Beschreibt die Schnittstellen des Systems zur Umwelt
• Es nimmt im SA-Modell eine Sonderstellung ein, was Syntax und
S
Semantik
tik b
betrifft:
t ifft
 Enthält nur einen Prozess, der die Nummer 0 enthält 0.
und das Gesamtsystem repräsentiert .




Enthält mindestens eine Schnittstelle.
Zwischen den Schnittstellen gibt es keine Datenflüsse.
Enthält keinen Speicher.
Jede Schnittstelle ist i. A. nur einmal vorhanden
° Ausnahme:
A
h
Übersichtlichkeit
Üb
i htli hk it
D1
A
A
D2
D1
D2
Vorlesung: 9
Seite 8
SWT – SA/RT
Kontextdiagramm - semantische Regeln
• Beschreibt Anwendungsbereich des zu modellierenden Systems
(problem domain).
• Zeigt Datenflüsse, die Systemgrenzen passieren.
• Ist die Zusammenfassung von Diagramm 0. (siehe Folie 7)
• Kann es von derselben Schnittstelle mehrere Instanzen geben,
wird sie einmal dargestellt.
• Gibt es wenige gleichartige Schnittstellen mit unterschiedlichen
Datenflüssen, dann getrennte Darstellung.
• Schnittstelle muss ursprüngliche Quelle oder Senke einer
I f
Information
ti
angeben
b
• Wahl einer Schnittstelle abstrahiert von der konkreten Eingabe
oder Ausgabe.
 d.
d h.
h Tastatur
T t t und
dD
Drucker
k i.
i A.
A keine
k i
Schnittstelle.
S h itt t ll
D1E
S1
D1A
Schnitt stelle z ur
U
Umw
elt
l
P
0.
D 2E Eingabedatenfluss
S2
D 2 A Ausgabedatenfluss
Dat enfluss- Prozess, rep räsen tiert das
name
G
Gesam
tsystem, gekenn
k
zeichet
i h du
d rch
h 0.
0
Vorlesung: 9
Seite 9
SWT – SA/RT
Beispiel Kontextdiagramm
Firma
Kundensachbearbeiter
Dozent
Anfrage
edaten
Firmenb
buchungsdaten
Mitteilungsschreib
ben
Rechnung
en
Urkunde
Kunde
Verwalte
Seminare
und Kunden
0.
Durchführungsbestätigung
Veranstaltungsbetreuer
Seminar
Sachbearbeiter
Kontextdiagramm der
Seminarorganisation
Buchhaltung
Vorlesung: 9
Seite 10
SWT – SA/RT
Abstraktion
•
•
•
•
•
Datenflüsse auf angemessenem Abstraktionsniveau beschreiben
Zu detailliert: Dann unübersichtlich, überladen
Zu abstrakt: Dann nichtssagend
Richtschnur:
 Anhand des Kontextdiagramms müssen für einen Außenstehenden
die wesentlichen Informationen über die Umwelt erkennbar sein.
sein
 Namensgebung muss problembezogen sein.
 Alle Datenflüsse auf demselben Abstraktionsniveau.
Beispiel »Animation eines Roboter«:
 Da die Animation im Mittelpunkt steht, ist Grafikbildschirm eine
eigene Schnittstelle.
 Modelliert man auch die Ansteuerung eines Roboters,
Roboters kommt die
Schnittstelle Robotersteuerung hinzu.
Bediener des
Roboters
Kommandos
Roboter
Animieren
0.
Grafikbildschirm
Robotersteuerung
Vorlesung: 9
Seite 11
SWT – SA/RT
DFD 0 = Verfeinerung des Kontextdiagramms
• Regeln
 Prozess 0 wird in Teilprozesse (hier: P1 und P2) zerlegt
 Datenflüsse werden ebenfalls verfeinert (hier: D1E und D2E)
 Speicher werden eingeführt (hier: Speicher 1).
D2E1
D1E1
P1
.1
D1A
D2E2
DP12
Speicher 1
D1E2
P2
.2
DD:
D1E = D1E1 + D1E2
D2E = (D2E1) + D2E2
D2A
Vorlesung: 9
Seite 12
SWT – SA/RT
DFD: Eigenschaften und Regeln
Verfeinerte DFD‘s




Prozess 0 im Kontextdiagramm wird in Teilprozesse gegliedert
Darstellung erfolgt im Diagramm 0 (DFD 0).
Jeder Prozess wird fortlaufend nummeriert
nummeriert.
Es werden Speicher eingefügt
° Ist die Ermittlung der Anzahl und Struktur der Speicher schwierig,
sollte zunächst ein ER-Modell erstellt werden.
° Evtl. die im ER-Modell gefundenen Speicher für die Darstellung im
SA-Modell komprimiert als Datenbasis darstellen.
Regeln für DFDs








Schnittstellen können nicht verfeinert werden.
Speicher können nicht verfeinert werden.
Speicher und Schnittstellen können aber auf allen Verfeinerungen unverändert
wiederholt werden.
A
Anzahl
hl der
d P
Prozesse auff einem
i
Diagramm
Di
soll
ll nicht
i ht größer
öß als
l 7 sein.
i
Abstraktionsniveau der Prozesse und Datenflüsse sollte gleich sein.
Prozesse werden von 1 beginnend fortlaufend nummeriert.
Vor jeder Zahl steht ein Punkt: .1, .2, .3
Jedes Diagramm trägt die Nummer, die seine Stellung in der Hierarchie angibt
° DFD 4.3: Verfeinerung des Prozesses 3 des DFD 4

Zur eindeutigen Kennzeichnung wird vor jeden Prozess die DFD-Nummer gesetzt
° Prozess
P
4.3.1:
4 3 1 1.
1 Prozess
P
im
i Diagramm
Di
4.3
43

Die Nummernsystematik wird i. A. vom eingesetzten CASE-Werkzeug verwaltet.
Vorlesung: 9
Seite 13
SWT – SA/RT
DFD 0: Verwalte Seminare und Kunden der
Seminarorganisation
Auskünfte
Firmenbuchungsdaten
Mitteilungsschreiben
Rechnung
Auskünfte
Buchungsdaten
Mitteilungsschreiben
Rechnung
.5
Verwalte
Firmen
Anfragedaten
Anfragen
Infos an
Dozenten
Dozentendaten
.1
Verwalte
Dozenten
.4
Verwalte
Kunden
Rechnungsdatensätze
.6
Lese
Rechnungsd
daten
DFD 2
Datenbasis
Seminare und Kunden
.3
ZahlungsVerzüge
einzahlen
hl
.2
Verwalte
Seminare
Urkunden
Teilnehmerliste
Seminaranfragen
Seminardaten
Seminarauskünfte
Vorlesung: 9
Seite 14
SWT – SA/RT
DFD 2: Verwalte Seminare in der Seminarorganisation
Sem i n artyp d aten
.1
erfas se
än d ere
lö sc h e
Se min arty p en
.2
er fas se,,
än d e re, lö s ch e
Sem in ar veran s tal tu n g en
Sem in ar an fr ag ed aten
Se min arau s kü n f te
.3
sto rn iere
b z w. b e stätig e
Sem in ar verver
an staltu n g en
.4
er stel le
Tei ln ehm erl is te
Da tenb a sis
Sem inare u nd K u n d en
.6
b ean tw o r te
Sem in aran fr ag en
Ve ran staltun g s Nr
.5
ers telle
Urk u nd e n
Vorlesung: 9
Seite 15
SWT – SA/RT
Data Dictionary-Einträge und Datenintegrität I
Verfeinerung der Daten
 Parallel zur Verfeinerung der DFDs und der Prozesse werden auch die
Daten verfeinert.
 Jeder Datenflusspfeil erhält einen Datenflussnamen
° Ausnahme: Datenfluss geht zum oder kommt vom Speicher und greift auf den
gesamten Inhalt zu.
 Jeder Datenflussname ist im Data Dictionary definiert.
definiert
 Jeder Speicher trägt einen Namen.
 Jeder Speichername ist im Data Dictionary definiert.
Beispiel »Seminarorganisation«:
 Beim Übergang vom Kontextdiagramm auf DFD 0 wurden keine
Datenflüsse verfeinert.
 Es wurden neue Datenflüsse zwischen Speichern und Prozessen eingefügt.
 In DFD 4 (Verwalte Kunden) wurden Datenflüsse verfeinert, dies muss im
Data Dictionary festgehalten werden:
A f
Anfragedaten
d t
= P
Personaldaten
ld t
+ (Firmendaten)
(Fi
d t )
Buchungsdaten = Anmeldedaten + Abmeldedaten
 Sind die Datenflussnamen in mehreren DFDs identisch, dann handelt es
sich um die gleichen Datenflüsse.
Vorlesung: 9
Seite 16
SWT – SA/RT
Data Dictionary-Einträge und Datenintegrität II
•
•
•
Alle Datenflüsse des untergeordneten DFDs müssen entweder
 im übergeordneten DFD unter gleichem Namen erscheinen oder
 Teilkomponente eines Datenflusses sein und damit im DD beschrieben
werden.
Ist diese Eigenschaft zwischen allen Diagrammen erfüllt, spricht man von
einem ausbalancierten Datenmodell (balancing).
(balancing)
Vorteile ausbalancierter Datenmodelle:
 Einarbeitung in das System wird erleichtert, da nach dem
Kontextdiagramm keine neuen Datenflüsse hinzukommen.
 Stellt man auf tieferer Ebene einen fehlenden Datenfluss fest, dann kann
er neu eingezeichnet werden.
° Kann man den neuen Datenfluss als Teil eines bestehenden identifizieren,
braucht nur der DD-Eintrag ergänzt zu werden.
° Ist dies aus fachlicher Sicht nicht sinnvoll, dann muss auf allen übergeordneten
Diagrammen der neue Datenfluss nachträglich eingezeichnet werden.
•
SA-Hierarchiekonzept ist ein Makromechanismus
 Alle Datenflussdiagramme müssen innerhalb der Hierarchie ineinander
substituierbar sein (durch balancing sichergestellt).
 Es gibt keinen Schutzmechanismus
° Namen müssen global eindeutig sein.
Vorlesung: 9
Seite 17
SWT – SA/RT
Darstellungsmöglichkeiten von Datenflüssen
Symbolik
A
Erklärung
A fließt von links nach rechts
A
A wird in beide Zweige kopiert
B
A
C
A
B
C
A
X YZ
X,Y,Z
Kurzform für:
X
Y
Z
A teilt sich in die Komponenten B und C.
Impliziert, dass A keine weiteren Komponenten hat.
DD: A=B+C
A entsteht aus den Komponenten B und C.
Impliziert, dass A keine weiteren Komponenten hat.
DD: A=B+C
A fließt beide Wege entlang des Pfeils (meistens bei schreibendem
und lesendem Speicherzugriff)
X, Y und
X
d Z fli
fließen
ß
getrennt
t
t entlang
tl
d
des Pf
Pfeils
il ((von Werkzeugen
W k
i.A. nicht unterstützt)
Vorlesung: 9
Seite 18
SWT – SA/RT
Substituierte Hierarchie
A
C
1
a1
C
2
a2
a3
x
y
3.1
3
i2
i1
3.3
Ebene 0
Eb
Ebene 1
b2
B
Speicher
b1
3.2
4
a4
Ebene 2
Vorlesung: 9
Seite 19
SWT – SA/RT
Mini-Spezifikationen
•
•
•
Jeder Prozess, der nicht weiter verfeinert wird, muss durch eine MiniSpec
beschrieben werden.
p muss beschreiben,, wie die Eingaben
g
in die Ausgaben
g
Jede MiniSpec
transformiert werden.
Eine MiniSpec darf keine Implementierungsvorschriften enthalten.
MiniSpecs können Pseudocode, ET oder Entscheidungsbäume sein.
•
Beispiel: MiniSpec von Prozess 4.3.3 der »Seminarorganisation«
•
Stornierungsdaten
Mitt il
Mitteilung
S
Seminar
i
storniert
t
i t
.3
verwalte
Stornierungen
stornierte Rechnungsdaten
stornierte Rechnung
Scheckgutschrift
Stornierungsdaten aus der Datenbank lesen;
An alle Teilnehmer die Mitteilung Seminar storniert /F110/ versenden
if Teilnehmer hat Rechnung bereits gezahlt
then stornierte Rechnung und Scheckgutschrift mitversenden
end if
Stornierte Rechnungsdaten in Speicher Rechnungsdatensätze eintragen
eintragen.
Vorlesung: 9
Seite 20
SWT – SA/RT
Methodik
Schnittstellen
1. Festlegung der Schnittstellen zur Umwelt.
2. Identifizierung aller Eingabe- und
Ausgabedatenflüsse von den Schnittstellen zum
Prozess 0.
0 Vorläufige Datenflussnamen wählen.
wählen
Datenflüsse
a
3. Prozesse und Funktionen ermitteln, die Eingaben
in Ausgaben transformieren
transformieren. Vorläufige
Prozessnamen wählen!
Aufteilung
in Prozesse
4 Anzahl und Art der Speicher ermitteln,
4.
ermitteln evtl.
evtl ER
ERModell erstellen
Speicher,
u.U.ER-Modell
U ER M d ll
5 Verfeinern der ermittelten Datenflüsse und
5.
b
1
2
3
Datenflüsse
verfeinern
6. Zuordnung zu Prozessen und speichern der
Datenflüsse und Speicher im DD
Vorlesung: 9
Seite 21
SWT – SA/RT
Methodik
7. Überarbeiten des Modells. Dabei ist zu beachten:
 Initialisierung und Terminierung ignorieren
 Kontrollflüsse entfernen
 Triviale Fehlermeldungen weglassen
 Sorgfältige und eindeutige Namenswahl der Datenflüsse.
Evtl. neue Strukturierung des Systems
 Eindeutige Beschriftung aller Prozesse. Der Prozessname soll
alle Aktionen des Prozesses erfassen. Evtl. neue
Strukturierung des Systems.
8. Ausgehend von der konsolidierten Modellierung des
Kontextdiagramms und des Diagramms 0 schrittweise Erarbeitung
weiterer Ebenen
9 MiniSpecs für
9.
fü alle nicht weiter
eite verfeinerten
e feine ten Prozesse
P o esse erstellen
e stellen
10.Verfeinerung beenden, wenn jeder Prozess überschaubar ist. Nicht
unnötig tief verfeinern!
Vorlesung: 9
Seite 22
SWT – SA/RT
Hinweise zur Methodik
• Kontextdiagramm und Diagramm 0 können zunächst als ein
Diagramm entwickelt werden.
• Erst zum Schluss wird aus diesem Diagramm das
Kontextdiagramm abstrahiert.
• Kontextdiagramm und Diagramm 0 sind die entscheidenden
Diagramme.
• Sie sollten zunächst interaktiv ohne CASE-Werkzeug im Team
entwickelt werden.
• Bei umfangreichen Problemen zwei getrennte Teams einsetzen
und die Ergebnisse diskutieren.
Vorlesung: 9
Seite 23
SWT – SA/RT
Qualitätssicherung
• Vielfältige Analysen zur Qualitätssicherung können durchgeführt
werden.
• Jedes der Basiskonzepte kann separat überprüft werden.
• Syntax
S t
wird
i d durch
d
h CASE-Werkzeuge
CASE W k
geprüft.
üft
• Semantik kann mit einer Checkliste überprüft werden.
Vorlesung: 9
Seite 24
SWT – SA/RT
Bewertung der Strukturierten Analyse
• Vorteile
 Geschickte Kombination bewährter Basiskonzepte
 Durch
D ch hierarchisch
hie a chisch gegliede
gegliederte
te DFD Verbesserung
Ve besse ng der
de
Übersichtlichkeit
 Viele analytische QS-Möglichkeiten durch Quervergleiche der in
den Basiskonzepten beschriebenen Aspekte
 Leicht erlernbar
 Erlaubt eine top-down-Einarbeitung in ein System
 Guter Zusammenhang zu ER-Modellen
ER Modellen über Speicher herstellbar.
herstellbar
• Nachteile
 Schnittstellen
S h itt t ll
können
kö
nicht
i ht verfeinert
f i
t werden
d
° Bei umfangreichen Schnittstellen gibt es dann Darstellungsprobleme
 Speicher können nicht verfeinert werden
° A
Ausweg: Globale
Gl b l D
Datenbasis
b i verwenden,
d
V
Verfeinerung
f i
durch
d
h ein
i ERER
Modell beschreiben
 Es entsteht ein Strukturbruch, wenn ein SA-Modell in einen
datenabstraktionsorientierten Entwurf transformiert werden soll.
soll
Vorlesung: 9
Seite 25
SWT – SA/RT
Zusammenfassung
Die Strukturierte Analyse (SA, structured analysis) besteht aus
einem Hierarchiemodell, das die einzelnen DFD als Baum
anordnet.
d t W
Wurzell des
d Baumes
B
ist
i t das
d Kontextdiagramm.
K t tdi
Blätt
Blätter
des Baumes sind DFD, die nicht weiter verfeinert werden können.
Prozesse dieser DFD werden durch Mini-Spezifikationen
(MiniSpecs) beschrieben. Innerhalb eines SA-Modells, d. h. von
der Baumwurzel bis zu den Baumblättern, muss die
Datenintegrität
g
((balancing)
g) sichergestellt
g
sein,, d. h.,, die DFD
müssen zwischen Kind- und Elterndiagramm ausbalanciert sein.
Vorlesung: 9
Seite 26
SWT – SA/RT
Literatur
• Balzert H., Lehrbuch der Softwaretechnik, 2. Auflage, Spektrum
Akademischer Verlag,Heidelberg, 2000.
• DeMarco T. Structured Analysis and System Specification,
Yourdon Press, Englewood Cliffs, 1978
• Gane C., Sarson T., Stuctured Systems Analysis: Tools and
Techniques,
q
, Prentice-Hall,, Englewood
g
Cliffs,, 1979
• McMenamin S. M., Palemer J. F., Essential Systems Analysis,
Yourdon Press,
Press Englewood Cliffs,
Cliffs 1984
• Weinberg V., Structured Analysis, Yourdon Press, Englewood
Cliffs 1978
Cliffs,
Vorlesung: 9
Seite 27
SWT – SA/RT
Überblick LE 15
LE 14: Strukturierte Analyse
LE 15: Strukturierte Analyse/Real Time Analysis




Vergleich
e g e c SA
S und
u d SA/RT
S /
Datenflüsse vs. Kontrollflüsse
Zeitspezifikation
W t
Wertung
Vorlesung: 9
Seite 28
SWT – SA/RT
SA/RT und seine Basiskonzepte
RT
RT
1987
1987
ET (Entscheidungss
du gs
tabelle)
SA
1979
Entscheidungsbäume)
Datenflussfluss
diagramm
Data
Dictionary
ER
(Entity Re
Relationship)
PseudoCode
Zustandsautomaten
Informationsfl
fluss
Datenstrukturen
k
Entitätstypen
& Beziehungen
i h
Kontrollstrukturen
k
Endlicher
Automat
Legende:
A
A
B: A ist in B enthalten
B: A ist implizit in B enthalten
Vorlesung: 9
Seite 29
SWT – SA/RT
Vergleich SA und SA/RT
•
•
•
•
Defizite der Strukturierten Analyse
 Strukturierte Analyse verzichtet bewusst auf die Beschreibung der
Initialisierung
g und Terminierung
g eines Systems
y
 Zeitanforderungen können in SA nicht festgelegt werden
Realtime-Analysis erweitert Strukturierte Analyse so, dass ...
 ereignisgesteuerte Systeme mit
 Zeitanforderungen und
 komplexen Prozessaktivierungen
 modelliert werden können.
SA/RT ist
 Industriestandard.
 Erste Werkzeuge waren schon ein Jahr nach Vorstellung der Methode (1987)
verfügbar.
Echtzeitbegriff in SA/RT
 Es ist nur die Festlegung externer Zeitanforderungen möglich
° Diese werden keiner Analyse unterzogen
° Sie werden nur dokumentiert
 Zeitanforderungen
g
müssen keine Echtzeitanforderungen
g
sein
 Prinzipiell können auch kommerzielle Anwendungssysteme modelliert werden.
Vorlesung: 9
Seite 30
SWT – SA/RT
Datenflüsse vs. Kontrollflüsse
•
Datenflüsse (aus Strukturierter Analyse)
 Werden in den Prozessen verarbeitet bzw. transformiert.
 Werden als durchgezogene Linien dargestellt.
dargestellt
 Elementare Datenflüsse sind meistens kontinuierliche Signale.
 Kontinuierliches Signal kann einen beliebigen Wert innerhalb eines
Wertebereichs annehmen
° Beispiel: 0..250 km/h
•
 Ein Datenfluss kann auch ein diskretes Signal sein, wenn es selbst
verarbeitet wird.
Kontrollflüsse (neu in Realtime Analysis)
 Steuern die Verarbeitung
 Werden als gestrichelte Linien dargestellt
 Sind immer diskrete Signale
° Nehmen eine endliche Anzahl bekannter Werte an
– Beispiel: Druckknopf = [ gedrückt | nicht gedrückt ]
 Werden wie Datenflüsse im DD definiert (aber als Kontrollflüsse
gekennzeichnet)
° DD heißt dann Requirements Dictionary (RD)
 Unterscheidung zwischen Kontroll- und Datenflüssen oft schwierig.
Vorlesung: 9
Seite 31
SWT – SA/RT
Flussdiagramm
• Flussdiagramm (FD):
 Enthält sowohl Daten- als auch Kontrollflüsse
Beispiel:
Kontrollfluß
Pr ozeß K
1E
S1
D1A
Schnittstelle z ur
Umw elt
Datenflußname
P
0.
K2A Kontrollflußname
K2E
S2
D2E
Datenfl uß
FD0 = Verfeinerung des Kontextdiagramms
K1E
K2E
D 2E1
DP12
P1
P2
.1
.2
D 2E2
Speicher 1
RD:
D2E = D2E1 + D2E2
K1E
K2A
D1A
K2E
K2A
Balk en,,
ver weist auf CSpec
Vorlesung: 9
Seite 32
SWT – SA/RT
RT-Kontextdiagramm – Beispiel: Digitaluhr
Dru ckck
kn op f_2
Dru ckDr
ck
kn op f_1
Batt erie
.0
st el le
Uh r
Uhrend isp l ay
Vorlesung: 9
Seite 33
SWT – SA/RT
Flussdiagramm 0 (FD0) Beispiel: Digitaluhr
.3
ak
k tualisiere
t li i
Zeit
.1
1
Zeit
auf 0
stellen
Anzeige
.4
Stunden
blinken
.2
Normalzei t
anz eigen
.5
Stunde
um 1
erhöhen
Zeit
.9
Sek unde
auf 0
stellen
.8
Sek unden
b linken
.7
Minuten
um 1
erhöhen
.6
Minuten
blink en
Vorlesung: 9
Seite 34
SWT – SA/RT
Requirements Dictionary
• RD (Kontrollflüsse blau) - Beispiel Digitaluhr
Knopf 1
Knopf 2
Start
Anzeige
Blinkende Anzeige
Zeit
aktuelle Stunden
erhoehte Stunden
aktuelle Minuten
erhoehte Minuten
aktuelle Sekunden
Nullsekunde
Stunden
Minuten
Sekunden
blinkende Stunden
blinkende Minuten
blinkende Sekunden
= [gedrückt | nicht gedrückt]
= [gedrückt | nicht gedrückt]
= [Strom vorhanden | Strom nicht vorhanden]
= Stunden + Minuten + Sekunden
= [blinkende Stunden | blinkende Minuten | blinkende Sekunden]
= Stunden + Minuten + Sekunden
= Stunden
= Stunden
= Minuten
= Minuten
= Sekunden
= Sekunden
= 0 .. 23
= 0 .. 59
= 0 .. 59
= 0 .. 23
= 0 .. 59
= 0 .. 59
Vorlesung: 9
Seite 35
SWT – SA/RT
Kontrollspezifikationen
• Ermöglicht es über Entscheidungstabellen und/oder
Zustandsautomaten, Prozesse eines Flussdiagramms zu aktivieren
und zu deaktivieren.
deaktivieren
• Jedem Flussdiagramm kann eine Kontrollspezifikation (CSpec)
zugeordnet werden:
 Enthält Entscheidungstabellen und/oder
 Zustandsautomaten
• Zusammenhang zwischen CSpec und Flussdiagramm:
 Wird durch eine Balkennotation (bar) im FD beschrieben
 Kontrollflüsse, die Eingangsgrößen für eine CSpec sind, werden
mit der Pfeilspitze zum Balken gezeichnet
 Kontrollflüsse, die eine CSpec verlassen, führen vom Balken
weg.
Vorlesung: 9
Seite 36
SWT – SA/RT
Kontrollspezifikationen – Beispiel: Digitaluhr
• Nach Einlegen der Batterie:
 Zeitspeicher soll mit der Zeit 0 initialisiert werden, d.h. zuerst
muss der
d Prozess
P
„Zeit
Z it auff 0 stellen“
t ll “ aktiviert
kti i t werden.
d
• Ist die 0 im Speicher eingetragen, dann kann der Prozess
„Normalzeit anzeigen“ aktiviert werden.
• Wird Knopf 1 gedrückt, erfolgt ein Übergang in der Zustand
„Stunden stellen“
• Die Kontrollspezifikation (CSpec 0) besteht aus einem
Zustandsautomat und einer ET.
ET
Vorlesung: 9
Seite 37
SWT – SA/RT
Zustandsautomat von CSpec 0
Vorlesung: 9
Seite 38
SWT – SA/RT
Entscheidungstabelle von CSpec 0
• Prozessaktivierungstabelle
Vorlesung: 9
Seite 39
SWT – SA/RT
Zeitspezifikation
•
Zeitanforderungen
 Spezifikation von externen Zeitanforderungen
 Beziehen sich auf die Signale der Schnittstellen
 Zwei Arten von Zeitspezifikationen:
° Wiederholungszyklen
– Für externe,
externe elementare Ausgabesignale
– Wiederholungszyklen werden im Requirement Dictionary durch das
Attribut Rate festgelegt
° Eingabe-Ausgabe-Antwortzeiten
– Legen den erlaubten Antwortzeitbereich für jedes Eingabeereignis und das
resultierende Ausgabeereignis fest
•
Regeln für Zeitspezifikationstabelle
 Eingabeereignisse treten außerhalb des Systems ein
 Ausgabeereignisse sind Aktionen, die vom System ausgeführt werden
Ein- und Ausgabeereignisse sind im Requirements Dictionary definiert
 Ein
 Es darf kein Signal oder Wert in der Zeitspezifikationstabelle erscheinen,
das nicht im Requirements Dictionary enthalten ist
 Jedes externe Signal,
Signal das im RD aufgeführt ist,
ist sollte in der
Zeitspezifikationstabelle erscheinen, selbst wenn die Zeit unkritisch ist.
Vorlesung: 9
Seite 40
SWT – SA/RT
Zeitspezifikation – Beispiel Digitaluhr
•
Wiederholungszyklen
 Für externe, elementare Ausgabesignale
 Wiederholungszyklen werden im Requirements Dictionary durch das
Attribut Rate festgelegt
Stunden
Minuten
Sekunden
= 0..23
= 0..59
= 0
0..59
59
Rate: Alle 100 msec
Rate: Alle 100 msec
Rate: Alle 100 msec
• Eingabe-Ausgabe-Antwortzeiten
 Legen den erlaubten Antwortzeitbereich für jedes Eingabeereignis
und das resultierende Ausgabeereignis fest
 Zeitspezifikationstabelle
Eingabesignal
Ereignis
Ausgabesignal
Ereignis
Antwortzeit
Knopf1
gedrückt blinkende Stunden
Zahl anzeigen
<100 msec
Knopf1
p
gedrückt blinkende Minuten
g
Zahl anzeigen
g
<100 msec
Knopf1
gedrückt blinkende Sekunden
Zahl anzeigen
<100 msec
Knopf2
gedrückt blinkende Stunden
Zahl anzeigen
<200 msec
Knopf2
gedrückt blinkende Minuten
Zahl anzeigen
<200 msec
Knopf2
gedrückt blinkende Sekunden
Zahl anzeigen
<200 msec.
Vorlesung: 9
Seite 41
SWT – SA/RT
Bewertung von SA/RT
•
Vorteile
 Gut geeignet zur Modellierung ereignisgesteuerter Systeme
 Komplexe Steuerungszusammenhänge können beschrieben werden
 Zur Zeit keine vergleichbare bessere Methode zur Modellierung dieser
Anwendungsklasse verfügbar
 Gute Werkzeugunterstützung
•
Nachteile
 Schwieriger
S h i i
als
l St
Strukturierte
kt i t A
Analyse
l
zu erlernen
l
und
d zu verstehen
t h
 Wird leicht unübersichtlich, da eine CSpec aus mehreren Seiten
bestehen kann.
Vorlesung: 9
Seite 42
SWT – SA/RT
Zusammenfassung
Real-Time Analysis (RT) erweitert SA um die Möglichkeit, Prozesse
zu aktivieren und zu deaktivieren. Außerdem können
Zeitspezifikationen beschrieben werden. Um dies zu ermöglichen,
gibt es neben den Datenflüssen auch Kontrollflüsse, die Ereignisse
repräsentieren. DFD werden zu Flussdiagrammen verallgemeinert, die
zusätzlich Kontrollflüsse enthalten können. Die Prozess-Steuerung der
Prozesse die sich auf einem Flussdiagramm befinden
Prozesse,
befinden, erfolgt durch
einen zugeordnete Kontrollflussspezifikation (Cspec). Die in der
Kontrollflussspezifikation verwendeten Ein
Ein- und Ausgabensignale
werden durch eine Balken-Notation (bar) im zugeordneten
Flussdiagramm aufgeführt. Elementare Prozesse werden durch eine
Prozess-Spezifikation (PSpec) beschrieben (anderer Name für MiniSpezifikationen). Alle Flüsse und Speicher werden im Requirements
Dictionary (RD) definiert (anderer Name für Data Dictionary).
Vorlesung: 9
Seite 43
SWT – SA/RT
Literatur
• Balzert H., Lehrbuch der Softwaretechnik, 2. Auflage, Spektrum
Akademischer Verlag,Heidelberg, 2000.
• Hatley D. J., Pirbhai I. A. , Strategies for real-time system
specification, Dorset House Publishing, New York, 1987
• Ward P. T., Mellor S. J., Structured Development for Real-Time
y
, Volume 1: Introduction and Tools,, Yourdon Press,, 1985
Systems,
• Ward P. T., Mellor S. J., Structured Development for Real-Time
Systems Volume 2: Essential Modelling Techniques,
Systems,
Techniques Yourdon
Press, 1985
• Wa
Ward
d P.
P T
T., Mello
Mellor S
S. J.,
J Structured
St ct ed Development
De elopment for
fo Real-Time
Real Time
Systems, Volume 3: Implementation Modelling Techniques,
Yourdon Press, 1986
Vorlesung: 9
Seite 44

- Lehrstuhl für Betriebliche Informationssysteme

Transcription

Documents pareils

20.11.2007 - Lehrstuhl für Betriebliche Informationssysteme

TAB Wasser - Stadtwerke Trier

Steuertipp 06/2016

Übung 02. Collage-City

2010 03 01 Tab akuell mit Logo aktuell

Prozessmodellierung - Lehrstuhl für Betriebliche Informationssysteme

Formular Romanistik

u bahn london umgangssprachlich

Komponentenorientierte Softwareentwicklung ‚eclipse` und

SWT_Liniennetzplan 0113.indd

GUI-Programmierung

Hinweise zu den Mathematischen Vertiefungen