Zusammenfassung ZA und PN Modellierung

Zusammenfassung ZA und PN 

Zustandsautomaten: 

Systemreaktion auf Ereignisse abhängig von Folge vorangegangener 

Ereignisse: momentane und frühere Eingaben bestimmen Ausgabe und 

Folgezustände. 

z (t+∆) = f [z(t),e] beschreibt Dynamik, aber Verarbeitung (Funktion) nur 

elementar. 

Petri-Netze: 

Systemzustand bestimmt durch Markenverteilung auf die Stellen, beschrieben 

z.B. durch Markierungsvektor. Petri-Netz beschreibt Änderung der 

Markenverteilung (Zustandsänderung) durch Schalten von Transitionen. 

v v v 

v 

m t + ∆) 

= m( 

t) 

+ ∑ε 

t , ε ∈(0,1) : Eintreten des zu t gehörenden Ereignisses 

( 

j j j 

j 

v 

t j aktiviert 

beschreibt Dynamik, aber Verarbeitung (Funktion) nur elementar. 

Nächster Schritt: 

Verbindung von Basiskonzepten der Datentransformation (funktionale, 

algorithmische, regelbasierte und datenorientierte Sicht) mit den 

Basiskonzepten der zustandsorientierten Sicht in einer 

Modellierungsmethode: SA/RT 

Vorlesung Automatisierungsprojekte Seite 7/1 

Modellierung 

Basiskonzepte der SW-Entwicklung: Übersicht 

Konzepte und Sichten 

Alternative Notationen 

Häufig verwendet 

Selten verwendet 

Pro- 

gramm- 

Ablaufplan 

Struktogramm 

Entscheidungstabelle 

Aktivitätsdiagramm 

Kollaborationsdiagramm 

Funktionsbaum 

Geschäftsprozess 

Datenflussdiagramm 

Data 

Dictionary 

Regeln 

Entity 

Relationship 

Klassendiagramm 

Pseudocode 

Zustandsautomat 

Petri- 

Netz 

Sequenzdiagramm 

Funktionale Sicht 

Datenorientierte 

Sicht 

Interaktionsstrukturen 

Objektorient. 

Sicht 

Algorithm. 

Sicht 

Endlicher 

Automat 

Regelbasierte 

Sicht 

Zustandsorientierte 

Sicht 

Funktionale 

Hierarchie 

Arbeitsablauf 

Informationsfluss 

Datenstrukturen 

Entitätstypen 

u. 

Beziehungen 

Klassenstrukturen 

Kontrollstrukturen 

Wenn- 

dann- 

Strukturen 

Nebenläufige 

Strukturen 

Szenariobasierte 

Sicht 

Vorlesung Automatisierungsprojekte Seite 7/2

Modellierung 

Kombination der Basiskonzepte 

in „SA/RT“ oder auch „RT“ 

RT 

1987 

SA 

1979 


Entscheidungsbäume 

Funktions- 

Baum 


Data 

Dictionary 

Entity 

Relationship 

Pseudocode 

Zustandsautomat 

Funktionale 

Hierarchie 

Entitätstypen 

Beziehungen 




Endlicher 

Automat 


Strukturierte Analyse 

Kombination von Basiskonzepten in SA 

SA 

1979 



Zweck 

Funktions- 

Baum 


Zentrale 

Komponente 

Verfeinerungskonzept 

Data 

Dictionary 

Konsistenzhaltung 

Pseudocode 

Elementare 

Datentransformation 

dargestellt Funktionale 

Hierarchie 




Problem: Datenflussdiagramm bei umfangreichen Problemen unübersichtlich. 

Lösung: Hierarchische Verfeinerung der Datenflussdiagramme. 

Wurzel: Kontextdiagramm (abstraktes Datenflussdiagramm). 

Blätter: Beschreibung durch Mini-Spec in Form von Pseudo-Code, 

Entscheidungstabellen oder Entscheidungsbäumen. 



Kombination von vorhandenen Basiskonzepten in SA 

Basiskonzept Datenflussdiagramm 

SA 

1979 



Funktions- 

Baum 


Data 

Dictionary 

Pseudocode 

Funktionale 

Hierarchie 






SA Basiskonzept Datenflussdiagramm (DFD) 

DFD: Beschreibung 

• Wege (Flüsse) 

von 

• Daten und Informationen 

zwischen 

• Funktionen, 

• Speichern und 

• Schnittstellen 

• Transformationen 

von 

Daten und Informationen 

durch 

Funktionen 

Datenname 

Speichername 


Funktionsname 

Schnittstellenname 

Grundvorstellung: Das zu entwickelnde System laufe bereits: Welche 

Information fließt von wo nach wo durch das System? 




Umweltmodellierung (äußere Systemschnittstellen): 

Informationsquellen 

Informationen entstehen und 

Quelle 

fließen zu Funktion 

Informationssenken 

Informationen fließen aus 

Funktion und verschwinden 

Senke 

Funktionen transformieren eingehende 

Datenflüsse in ausgehende 

Datenflüsse 

schreibend 

lesend 

Speicher: 

Hilfsmittel zur Ablage von Informationen 

Speicher 

Schreib/Lese 




Syntaktische Regeln: 

1. Ein DFD enthält mindestens eine Schnittstelle 

2. Jede Schnittstelle nur einmal vorhanden 

3. Keine Datenflüsse zwischen Schnittstellen 

4. Jeder Datenfluss hat einen Namen, außer von und zu 

Speichern, wenn gesamter Speicherinhalt transportiert 

wird 

5. Keine direkten Flüsse zwischen Speichern 

6. Keine direkten Flüsse zwischen Schnittstellen und 

Speichern 

falsch 

Semantische Regeln: 

1. DFD beschreibt den Datenfluss und keinen Kontrollfluss 

2. Schnittstelle ist stets so zu wählen, dass sie die 

ursprüngliche Quelle oder Senke einer Information angibt. 

3. Datenflussnamen bestehen aus (Adjektiv und) Substantiv 

4. Funktionsname repräsentiert Aktion und besteht aus 

Aktionsverb und Substantiv (Objekt) 




Überprüfbarkeit von DFD 

Mittels „Handsimulation“: 

Man stelle sich vor, man wäre der Prozessor. 

Prüfung, ob man anhand der eingehenden Informationsflüsse die 

ausgehenden Informationsflüsse erzeugen kann. 

Bewertung von DFD 

• Leicht erstellbar und gut lesbar 

• Gut vermittelbar 

• Schwierig, einheitliches Abstraktionsniveau bei Daten und 

Funktionen einzuhalten 

• Diagramm schnell zu groß und unübersichtlich Hierarchie 

in SA 

• Bezeichnung der Datenflüsse durch Namen reicht nicht aus. 

• Datenaufbau muss bekannt sein, um bei Simulation Fehler zu 

finden. Data Dictionary in SA 




Aufgabe 

Verwaltung einer Arztpraxis: 

Neue Patienten werden in eine Patientenkartei aufgenommen, an der 

auch später noch Änderungen vorgenommen werden können. 

Erscheint ein Patient zur Behandlung, so werden dem behandelnden 

Arzt die Patientendaten und die Daten der letzten Behandlungen zur 

Verfügung gestellt. Nach der Behandlung werden das Datum, die 

erbrachten Leistungen und die Verordnungen gespeichert. 

Schnittstellen 

Funktionen 

Datenflüsse 




Verwaltung einer Arztpraxis 




Übung: Überprüfung fehlerhaftes DFD 



Das Datenflussdiagramm zur Kundenverwaltung enthält folgende Fehler: 

1. Der Datenfluss "erhöhe_Anzahl_der_Bestellungen" enthält ein Verb und 

führt von einem Prozess zum selben Prozess (Schleife). Richtig wäre es, 

einen Speicher "Anzahl_der Bestellung" einzuzeichnen, der lesend / 

schreibend von Prozess 1 benutzt wird. 

2. Der Name des Datenflusses "Anschrift" ist ungeschickt. Besser wäre es, ihn 

als "Kundenanschrift" zu bezeichnen. 

3. Die Speicher "Kundendatei" und "Rechnungen" sind direkt durch einen 

Datenfluss verbunden. Richtig wäre es, einen dritten Prozess "erstelle 

Rechnungen" einzuzeichnen, der die "Kundenanschrift", die 

"Artikelbezeichnung" und den "Artikelpreis" als Eingabedatenflüsse sowie 

"Rechnungen" als Ausgabedatenfluss besitzt. 

4. Ein Datenfluss von Speicher "Rechnungen" zu Schnittstelle "Kunde" ist 

nicht erlaubt. 

5. Der Datenfluss "Artikeldaten" von der Schnittstelle "Sachbearbeiter" direkt in 

den Speicher "Artikeldaten" ist nicht erlaubt. Richtig wäre es, einen Prozess 

"aktualisiere Artikeldateien" einzuzeichnen. 

6. Die Schnittstelle Kunde sollte nur einmal vorhanden sein, da die Lesbarkeit 

durch die getrennte Ausführung der Schnittstellen nicht erhöht wird. 




Übung für zuhause: Überprüfung fehlerhaftes DFD 




Basiskonzept Data Dictionary 

Data 

Dictionary 

SA 

1979 

??? 



Funktions- 

Baum 


Data 

Dictionary 

Pseudocode 

Funktionale 

Hierarchie 






SA Basiskonzept Data Dictionary (DD) 

Sammlung von Datendefinitionen (Glossar) + Verfeinerungskonzept 

Dient Konsistenzüberwachung eines Datenbestandes 

Übersicht über Datenstrukturen 

Überprüfung auf Redundanzfreiheit und Widerspruchsfreiheit 

Entsteht in Definitionsphase und wird in Entwurfs- und 

Implementierungsphase weiter verwendet und verfeinert. 

Notation: 

Symbol 

= 

+ 

[ ] 

{ } 

M{ }N 

( ) 

*...* 

Bedeutung 

Äquivalent zu 

Sequenz 

Auswahl (entweder ... Oder) 

Wiederholung 

Wiederholung von M bis N 

Option 

Kommentar 

Beispiel 

A = B + C 

X = X1 + X2 + X3 

A = [B | C] 

A = {B} 

A = 1{B}10 

A = B + (C) 

A = X + Y *sowas* 




Beispiel Speicherung Kundendaten Symbol 

= 

Kundendatei = {Kundeneintrag} + 

Kundeneintrag = Kunden-Nr. 

[ ] 

+ Name 

+ Adresse 

+ (Geburtsdatum) 

+ (Funktion) 

+ Umsatz 

Name = Anrede + (Titel) 

+ Vorname + Nachname 

Kommentar 

Adresse = [Straße + Hausnr. | Postfachnr.] 

+ (Länderkennzeichen) + PLZ + Ort + (Telefon) + (Fax) 

{ } 

M{ }N 

( ) 

*...* 

Bedeutung 

Äquivalent zu 

Sequenz 

Auswahl (entweder ... 

Oder) 

Wiederholung 

Wiederholung von M bis N 

Option 

Beispiel 

A = B + C 

X = X1 + X2 + X3 

A = [B | C] 

A = {B} 

A = 1{B}10 

A = B + (C) 

A = X + Y 

*sowas* 

Datendefinition Top-Down Schrittweise Verfeinerung 

Bis zum notwendigen Detaillierungsniveau oder „Datenatom“ 




Anwendungsregeln 

Wiederholungs- und Optionsklammern auf möglichst hoher 

Verfeinerungsebene (frühe Erkennbarkeit der Struktur) 

0. Keine zirkulären Definitionen 

A = B + C 

C = D + A ergibt A = B + D + A 

1. Unterschiedliche Bezeichnungen identischer Strukturen: 

Bezeichnungen können gleich gesetzt werden (Alias-Namen) 

2. Problembezogene Namen wählen, z.B. Kundenname statt Name 

3. Bereits definierte Datenstrukturen wiederverwenden, 

z.B. Kundenname = Name, wenn Name bereits definiert. 

4. Auswahl muss mindestens zwei Alternativen enthalten, z.B. 

A=[B|C]. 

5. „Kontinuierliche“ Datenelemente: Wertebereich, z.B. B=0 ... 255 

6. Diskrete Datenelemente: Aufführung der möglichen Werte, z.B. 

Familienstand=[ledig|verheiratet|geschieden|verwitwet] 

7. Semantische Randbedingungen, die nicht in DD-Notation 

formulierbar sind, als Kommentare 




Basiskonzept Pseudocode 

Pseudocode 

??? 

SA 

1979 



Funktions- 

Baum 


Data 

Dictionary 

Pseudocode 

Funktionale 

Hierarchie 






SA Basiskonzept Kontrollstrukturen: Pseudocode 


• Sequenz 

• Auswahl 

• Wiederholung 

• Aufruf anderer Algorithmen 

Pseudocode: 

1. Textuelle, halb-formale Darstellungsform von 

Kontrollstrukturen in Anlehnung an problemorientierte 

Programmiersprachen: 

Syntax und Wortsymbole, z.B. if, switch, while 

2. Anweisungen in verbaler Formulierung oder 

programmsprachlich angelehnter Notation. 




z.B. in Anlehnung an C 

Sequenz 

Auswahl 

Ein- oder 

zweiseitig 

Anweisung1; 

Anweisung2; 

Anweisung3; 

if (bedingter Ausdruck) 

Ja-Anweisung; bzw. {Ja-Anweisungsblock} 

else 

Nein-Anweisung; bzw. {Nein-Anweisungsblock} 

Auswahl switch (Ausdruck) 

mehrfach { 

case Wert1: Anweisung1; bzw. {Anweisungsblock1}; break; 

case Wert2: Anweisung2; bzw. {Anweisungsblock2}; break; 

default: Anweisung_d; bzw. {Anweisungsblock_d} 

} 




z.B. in Anlehnung an C 

Wiederholung 

Mit Abfrage 

vor jedem 

Durchlauf 

Wiederholung 

Mit Abfrage 

nach jedem 

Durchlauf 

while (Bedingung) 

Anweisung; bzw. {Anweisungsblock} 

Anweisung3; 

do Anweisung; bzw. {Anweisungsblock} 

while (Bedingung) 

Wiederholung for (Startwerte; Bedingung; Veränderung) 

Mit bestimmter { 

Anzahl von 

Anweisung; bzw. {Anweisungsblock} 

Wiederholungen } 

Aufruf 

Operationsname (aktuelle Parameter); 




Basiskonzept Entscheidungstabelle 


??? 

SA 

1979 



Funktions- 

Baum 


Data 

Dictionary 

Pseudocode 

Funktionale 

Hierarchie 






SA Basiskonzept Kontrollstrukturen: Entscheidungstabellen 

Kompakte Definition bedingter Handlungen (eine oder mehrere 

Bedingungen) in Form einer Tabelle 

Name der ET 

Regelnummern 

Wenn 

Dann 

Bedingungen 

Aktionen 

Bedingungsanzeiger 

Aktionsanzeiger 

Darstellung von wenn ..., dann ...-Sachwissen (Regeln). 




Beispiel: 

Scheckeinlösung durch Banksachbearbeiter 

Wenn Kreditgrenze des Ausstellers überschritten, bisheriges 

Zahlungsverhalten aber einwandfrei war und der 

Überschreitungsbetrag kleiner als 500 € ist, dann soll Scheck 

eingelöst werden. 

Wenn Kreditgrenze des Ausstellers überschritten, bisheriges 

Zahlungsverhalten aber einwandfrei war und der 

Überschreitungsbetrag über 500 € ist, dann soll Scheck eingelöst 

und dem Aussteller neue Konditionen vorgelegt werden. 

Wenn das Zahlungsverhalten nicht einwandfrei war, wird der Scheck 

nicht eingelöst. 

Wenn die Kreditlinie nicht überschritten wird, wird der Scheck 

eingelöst. 




Beispiel: 


Analyse: 

1. Aktionen ermitteln 

A1: Scheck einlösen 

A2: Scheck nicht einlösen 

A3: Neue Konditionen vorlegen 

2. Bedingungen ermitteln: 

B1: Kreditgrenze überschritten ? 

B2: Zahlungsverhalten einwandfrei ? 

B3: Überschreitungsbetrag < 500 € ? 




Beispiel: 


Tabelle erstellen 

ET1 

Scheckeinlösung 

R1 

R2 

R3 

R4 

R5 

R6 

R7 

R8 

B1 

Kreditgrenze 

überschritten ? 

J 

J 

J 

J 

N 

N 

N 

N 

B2 

Zahlungsverhalten 

einwandfrei ? 

J 

J 

N 

N 

J 

J 

N 

N 

B3 

Überschreitungsbetrag 

< 500€ ? 

J 

N 

J 

N 

J 

N 

J 

N 

A1 

Scheck einlösen 

X 

X 

X 

X 

A2 

Scheck nicht 

einlösen 

X 

X 

A3 

Neue Konditionen 

vorlegen 

X 

A4 

unlogisch 

X 

X 

Vorlesung Automatisierungsprojekte löschen Seite 7/27 



Vereinfachung 

Erinnerung: Blockbildung in Funktionstabelle 

R1 

R2 

B1 Kreditgrenze 


1 

1 

B2 


einwandfrei ? 

1 

1 

B3 Überschreitungsbetrag 

< 500 € ? 

1 

0 

A1 Scheck einlösen 

1 

1 

zusammenfassen 

R3 

1 

0 

1 

0 

R4 

1 

0 

0 

0 

R5 

0 

1 

1 

1 

R6 

R7 

0 

0 

1 

0 

0 

1 

- 

1 

zusammenfassen 

R8 

0 

0 

0 

- 




Vereinfachung der Tabelle 

Zusammenfassen 

Zusammenfassen 

ET1 


R1 

R2 

R3 

R4 

R5 

R6 

R7 

R8 

B1 

Kreditgrenze 


J 

J 

J 

J 

N 

N 

N 

N 

B2 


einwandfrei ? 

J 

J 

N 

N 

J 

J 

N 

N 

B3 


< 500€ ? 

J 

N 

J 

N 

J 

N 

J 

N 

A1 


X 

X 

X 

X 

A2 

Scheck nicht 

einlösen 

X 

X 

A3 


vorlegen 

X 

A4 

unlogisch 

X 

X 

Nicht gleiche Gleiche 

löschen 

Aktion Aktion Gleiche 

Vorlesung Automatisierungsprojekte Aktion 

Seite 7/29 



Vereinfachung der Tabelle durch Zusammenfassung 

ET1 

B1 


Kreditgrenze 


R1 

J 

R2 

J 

R3/ 

4 

J 

R5/ 

7 

N 

B2 


einwandfrei ? 

J 

J 

N 

- 

B3 


< 500€ ? 

J 

N 

- 

J 

A1 


X 

X 

X 

A2 

Scheck nicht 

einlösen 

X 

A3 


vorlegen 

X 




Vereinfachung der Tabelle durch „else“-Regel 

Wenn im Beispiel R6 und R8 nicht unlogisch wären, sondern im 

Aktionsanzeigerteil auch nur A1 besäßen, könnte die Tabelle durch „else“ 

vereinfacht werden: 

ET1 

B1 


Kreditgrenze 


R1 

J 

R2 

J 

R3/ 

4 

J 

R5/ 

7 

N 

ET1 

B1 


Kreditgrenze 


R2 

J 

R3/ 

4 

J 

else 

B2 


einwandfrei ? 

J 

J 

N 

- 

B2 


einwandfrei ? 

J 

N 

B3 


< 500€ ? 

J 

N 

- 

J 

B3 


< 500€ ? 

N 

- 

A1 


X 

X 

X 

A1 


X 

X 

A2 

Scheck nicht 

einlösen 

X 

A2 

Scheck nicht 

einlösen 

X 

A3 


vorlegen 

X 

A3 


vorlegen 

X 



SA Basiskonzept Kontrollstrukturen: Entscheidungsbäume 

Alternative Darstellungsform der Entscheidungstabelle 

Überschr.- 

betr. < 500€ 

Zahlungsverh. 

einwandfr. 

Kreditgrenze 

überschr. 

Überschr.- 

betr. > 500€ 

Überschr.- 

betr. < 500€ 

Zahlungsverh. 

nicht einwandfr. 

Überschr.- 

betr. > 500€ 

Überschr.- 

betr. < 500€ 

Zahlungsverh. 

einwandfr. 

Kreditgrenze 

nicht überschr. 

Überschr.- 

betr. > 500€ 

Überschr.- 

betr. < 500€ 

Zahlungsverh. 

nicht einwandfr. 


Überschr.- 

betr. > 500€ 

unlogisch 

Scheck 

einlösen 

unlogisch 

Scheck 

einlösen 

Scheck nicht 

einlösen 

Scheck nicht 

einlösen 

Scheck nicht 

Einlösen, 

neue Kond. 

Scheck 

einlösen 




Tabellengröße im Bedingungsteil wächst mit 2 N (N: Anzahl der 

Bedingungen) nicht mehr handhabbar ab N=5. 

Abhilfe durch Aufspaltung in mehrere Entscheidungstabellen, z.B. 

Verzweigung: 

ET0 

R1 R2 R3 R4 

B1 

J 

J 

N 

N 

B2 

J 

N 

J 

N 

A1 

X 

X 

A2 

X 

X 

Weiter bei ET: 

ET1 

ET2 

ET3 

ET1 

R1.1 

R1.2 

R1.3 

R1.4 

B3 

J 

J 

N 

N 

B4 

J 

N 

J 

N 

A1.1 

X 

X 

A1.2 

X 

X 

X 




Erweiterte Entscheidungstabellen 

Bisher begrenzte ET: Bedingungsanzeiger J,N,- 

Aktionsanzeiger X 

Jetzt: beliebiger Text im Anzeigerteil 

Text im Bedingungsanzeiger muss erfüllt sein. 

Aktionsanzeigertext ist auszuführen. 

Beispiel Tarifdschungel einer Airline mit Zielen A und B: 

- Personenalter >= 18a: Ferientarif (-20%) falls Abflug zw. 21.12. und 

30.12. und 6 Tage Mindestaufenthalt 

- Für A kein Ferientarif 

- Personenalter < 18a: kein Ferientarif 

- 2a



Erweiterte Entscheidungstabellen 

Tarifdschungel 

R1 

R2 

R3 

R4 

R5 

R6 

Alter? 

Ziel 

>= 18 

B 

>= 18 

A 

>= 18 

B 

>= 18 

B 

>=2 u. < 

18 

- 

= 6 Tage 

J 

- 

N 

- 

- 

- 

Abflug zw. 

21.12. und 

30.12. 

J 

- 

- 

N 

- 

- 

Rabatt % 

20 

0 

0 

0 

30 

100 




Eintreffer- und Mehrtreffer-Entscheidungstabellen 

Eintreffer-Tabellen: 

Höchstens eine der Regeln ist anwendbar, d.h. die Bedingungen im 

Bedingungsanzeigerteil schließen sich gegenseitig aus. Abbruch nach 

Auffinden gültiger Regel. 

Mehrtreffer-Tabellen: 

Bedingungen brauchen nicht disjunkt zu sein. Sie können identisch, 

überschneidend, einschließend und gegenseitig ausschließend sein. 

Alle Regeln müssen überprüft werden. 

Aktionen aller gültigen Regeln werden ausgeführt. Widerspruchsfreiheit ! 

Gleichheit: Redundanz, Widerspruch oder Zusammenfassbarkeit 

- Löschen redundanter Regeln 

- Modifikation bei widersprüchlichen Regeln (widersprüchliche 

Aktionsteile von gleichlautenden Bedingungsanzeigern) 

- Zusammenfassung widerspruchsfreier Aktionsteile von 

gleichlautenden Bedingungsanzeigern 




Übung 

Umwandlung einer Tabelle in einen Entscheidungsbaum 




Übung 

Umwandlung einer Tabelle in einen Entscheidungsbaum 

B1 erfüllt 

B1 nicht erfüllt 




Übung 

Aufgabe „Bestellannahme“ 

Ist der Besteller noch nicht im Kundenstamm enthalten, soll eine Ersterfassung erfolgen. 

Ist ein bestellter Artikel verfügbar, muss der Lagerbestand aktualisiert werden. Falls ein 

Artikel nicht verfügbar ist, muss dies dem Besteller mitgeteilt werden. 

Hat der Besteller seinen Kreditrahmen überschritten, können keine weiteren 

Bestellungen erfolgen. Bei Kunden mit großem Umsatz soll dennoch der Auftrag 

ausgeführt werden. 

Mit der Auftragsbestätigung soll eine Rechnung erstellt und ausgedruckt werden. 

Ist bei einem Artikel der Mindestlagerbestand unterschritten, so ist der Sachbearbeiter 

zu informieren. 

Ist eine sofortige Bearbeitung wegen Nichtverfügbarkeit eines Artikels oder wegen 

Überschreitung der Kreditlinie des Kunden nicht möglich, soll diese Bestellung 

"eingefroren" werden. 

a) Bedingungen und Aktionen für eine Entscheidungstabelle ? 

b) Entscheidungstabelle, welche die Annahme von Bestellungen spezifiziert. 




Übung 

Aufgabe „Bestellannahme“ 

Ist der Besteller noch nicht im Kundenstamm enthalten, soll eine Ersterfassung erfolgen. 

Ist ein bestellter Artikel verfügbar, muss der Lagerbestand aktualisiert werden. Falls ein 

Artikel nicht verfügbar ist, muss dies dem Besteller mitgeteilt werden. 

Hat der Besteller seinen Kreditrahmen überschritten, können keine weiteren 

Bestellungen erfolgen. Bei Kunden mit großem Umsatz soll dennoch der Auftrag 

ausgeführt werden. 

Mit der Auftragsbestätigung soll eine Rechnung erstellt und ausgedruckt werden. 

Ist bei einem Artikel der Mindestlagerbestand unterschritten, so ist der Sachbearbeiter 

zu informieren. 

Ist eine sofortige Bearbeitung wegen Nichtverfügbarkeit eines Artikels oder wegen 

Überschreitung der Kreditlinie des Kunden nicht möglich, soll diese Bestellung 

"eingefroren" werden. 

a) Bedingungen und Aktionen für eine Entscheidungstabelle ? 

b) Entscheidungstabelle, welche die Annahme von Bestellungen spezifiziert. 




Übung 

B1 

B2 

B3 

B4 

B5 

B6 

A1 

A2 

A3 

A4 

A5 

A6 

Im Kundenstamm? 

Artikel verfügbar? 

Mindestbestand unterschritten? 

Kreditrahmen überschritten? 

Umsatz eines Großkunden? 

Bestellung trotz Überschreitung des Kreditrahmens 

In Kundenstamm aufnehmen 

Lagerbestand aktualisieren 

Kunden über Nichtverfügbarkeit des Artikels informieren 

Bestellung "einfrieren" 

Auftragsbestätigung und Rechnung erstellen 

Sachbearbeiter über Unterschreitung des Mindestbestandes informieren 




Übung: Fehlerhafte Lösung korrigieren 

x 

A5 

x 

ET3 

ET3 


Zwiziwzrrg fdggg oi oiw 

Oihdshf öhjfsodf pweufr 

Pwoijdlkjdsljflj eiurowifr8 ifi 

Oiroiroiurouroufdjdljdlu eeur 










Hierarchiekonzept in SA 

Kontext-Diagramm 

System (0) mit Schnittstellen 

zur Umwelt 

A 

B 

0 

C 

Diagramm 0 

System (0) verfeinert durch 

Funktionen 1, 2, 3 und 4 

b2 

a1 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

C 

Diagramm 3 

Funktion 3 verfeinert durch 

Funktionen 3.1, 3.2 und 3.3 

x 

3.1 

e2 

e1 

3.2 

3.3 

a3 

a4 

MiniSpec 3.1 




A 

Schnittstellen des zu modellierenden 

0 

C 

Systems zu seiner Umwelt. 

B 

Syntaktische Regeln: 

1. Nur ein Prozess mit Nummer 0: Repräsentiert Gesamtsystem 

2. Mindestens eine Schnittstelle 

3. Keine Datenflüsse zwischen den Schnittstellen 

4. Kein Speicher 

5. Jede Schnittstelle nur einmal vorhanden 

Semantische Regeln: 

1. Kontextdiagramm beschreibt Anwendungsbereich (problem domain) des 

zu modellierenden Systems 

2. Kontextdiagramm zeigt Datenflüsse, die Systemgrenzen passieren 

3. Kontextdiagramm stellt die zusammengefasste Form von Diagramm 0 

dar. 

4. Steht eine Schnittstelle für eine Vielzahl von beliebigen Instanzen, wird 

sie als eine Schnittstelle dargestellt. 

5. Eine Schnittstelle gibt die ursprüngliche Quelle oder Senke einer 

Information an. 


Status, 

dock 

info, 

images 



Beispiel DGS 

Schnittstellen des zu modellierenden Systems 

zu seiner Umwelt. 

A 

B 

0 

C 

Central Monitoring 

and Surveillance 

System (CMS) 

Airfield 

camera 

Video data 

Pilot 

Display 

Status, dock 

info, images 

Type, gate 

arrival time 

Guidance 

information 

Central 

Personal 

Commands 

0 

Docking 

Guidance 

System 

time 

on 

time 

off 

Airfield 

Lighting 

A/C models 

Data 

Base 

Gate occupation 

Status, dock 

info, images 

Calib. Data, chocks, 

On/off, engage, test, 

A/C type, gate arrival 

time 

User defined 

Gate Systems 

Ground 

Personel 




Beispiel DGS 

Schnittstellen des zu modellierenden Systems 

zu seiner Umwelt. 

A 

B 

C 



Verfeinerung Datenfluss-Diagramm 

Beispiel DGS 

Gate occupation 

Video data 

2 

Erfasse 

Andockvorgang 

Guidance 

information 

1 

Verwalte 

Andockvorgänge 

Status, Pose, 

Zeit 

Beginn/Ende Andockvorgang 

3 

Zeige an Leitinformation 

Type, gate 

arrival time 

Status, dock 

info, images 

Status, Pose, 

Zeit 

Steuerbefehle 

8 

Kommuniziere 

mit 

Zentralpers. 

Andock-Daten (Status, Pose, Zeit) 

Status, 

Pose 

Flugzeugtyp 

Commands 

Status, dock 

info, images 

Typspezifische 

Flugzeug-CAD-Daten 

Kalibrierdaten 

7 

Greife auf 

Datenbasis 

zu 

Status, 

Zeit 

Status, Pose, Zeit 

Steuerbefehle 

Animationsdaten 

Gate- 

Modell 

Bilddaten 

5 

Kalibriere 

Gatesystem 

a1 

6 

Kommuniziere 

mit Ground 

Operator 

b2 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

A/C models 

4 

Schalte 

Rollfeldbeleuchtung 


Kalibrierinformation 

Plandaten 

Beleuchtungs- 

Steuerdaten 

Meldungen 

C 

Kommandos, 

(A/C type), 

(gate arrival time) 



Prozess 0 repräsentiert das gesamte zu modellierende 

System. 

Untergliederung in Teilprozesse 

Regeln: 

b2 

a1 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

C 

1. Schnittstellen nicht verfeinerbar, können aber in verfeinerten Diagrammen 

zur Verdeutlichung nochmals dargestellt werden (eindeutige Benennung!). 

2. Speicher können nicht verfeinert werden, können aber in allen weiteren 

Verfeinerungen nach ihrer Einführung nochmals dargestellt werden 

(eindeutige Benennung!). 

3. Anzahl der pro Diagramm dargestellten Prozesse sollte < 8 sein, dann 

(oder wenn das Diagramm bereits zuvor unübersichtlich) neues Diagramm. 

4. Verfeinerung der Prozesse Verfeinerung der Datenflüsse; Ziel: 

einheitliches Abstraktionsniveau innerhalb eines Diagramms. 

5. Prozessnummerierung: Trägt am Anfang die Nummer des verfeinerten 

Prozesses, durch „.“ getrennt laufende Nummerierung ab 1. 




Beispiel DGS 

b2 

a1 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

C 




Data Dictionary Einträge und Datenintegrität (balancing) 

a3 Speicher 

a2 

3 a4 4 

b1 

Verfeinerung Prozesse Verfeinerung Datenflüsse 

Welche Datenflüsse zwischen zwei Diagrammen gehören wie zusammen ? 

a1 

b2 

1 2 

C 

Zusammenhang über Data Dictionary Einträge Forderungen: 

1. Jeder Datenflusspfeil hat einen Datenflussnamen (mögl. Ausnahme 

gesamter Speicher). 

2. Jeder Datenflussname ist im Data Dictionary definiert. 

3. Jeder Speicher hat einen Namen. 

4. Jeder Speichername ist im Data Dictionary definiert. 

5. Alle Datenflüsse eines untergeordneten DFD müssen im übergeordneten 

DFD entweder unter gleichem Namen erscheinen oder Teilkomponente 

eines Datenflusses sein. Die Teilkomponenten-Eigenschaft muss im DD 

beschrieben sein. 

Eigenschaft erfüllt: Ausbalanciertes Datenmodell (balancing), Datenintegrität 















Data Balancing mittels DD 

A = ? 

A 

0 

C 

B = ? 

B 

X = ? 

a1 

b2 

1 2 

C 

a3 Speicher 

a2 

3 a4 4 

b1 

e2 

3.2 

a3 

x 

3.1 

e1 

3.3 

a4 




Datenfluss-Darstellung 

A 

A fließt von links nach rechts 

A 

A 

A wird in beide Zweige kopiert 

b2 

a1 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

C 

A 

A 

B 

C 

B 

C 

A 

A teilt sich in Komponenten B und C. 

A hat keine weiteren Komponenten. 

DD: A=B+C 

A entsteht aus B und C; DD: A=B+C 

A fließt beide Richtungen entlang 

z.B. Schreib/Lese-Zugriff 




Hierarchiekonzept von SA 

b2 

a1 

1 2 

a3 Speicher 

a2 

3 a4 4 

b1 

C 

Durch Datenintegrität ist sichergestellt, dass alle Datenflussdiagramme – 

entsprechend ihrer Hierarchie- ineinander substituiert werden. 

Ein Datenfluss ist dann von innen nach außen und umgekehrt 

ununterbrochen verfolgbar. 

Speicher 




Mini-Spezifikationen (MiniSpec) 

a3 Speicher 

a2 

3 a4 4 

b1 

Letzte Stufe der Verfeinerung 

Jeder Prozess, der nicht durch weiteres DFD verfeinert wird, muss durch 

MiniSpec beschrieben werden. 

MiniSpec beschreibt, wie Daten, die in den Prozess hineinfließen, in Ausgaben 

transformiert werden. 

Beschreibungsmittel: Pseudocode, Entscheidungstabellen und -bäume 

a1 

b2 

1 2 

C 

Gate-Plandaten 

Andockdaten 

Erzeuge 

Display- 

Information 

Textdaten 

Abstandsdaten 

If ((Flugzeug detektiert)&&(Flugzeugmodell aus Gate-Plandaten passt nicht) 

then Textdaten = „Stop“ 

... 



Anwendung Werkzeug 



Vorgehen 

Iterativer Prozess, d.h. mehrere Modellierungsdurchläufe 

1. Festlegung der Systemschnittstellen zur Umwelt 

2. Identifizierung aller E/A-Datenflüsse von Schnittstellen zu Prozess 0 

3. Ermitteln Funktionen bzw. Prozesse, die Eingaben in Ausgaben 

transformieren 

4. Speicher identifizieren und festlegen 

5. Verfeinerung von Prozessen und Flüssen 

6. Definition der Speicher und Datenflüsse im Data Dictionary 

7. Iterative Überarbeitung 

1. Eventuelle Kontrollflüsse entfernen 

2. Eindeutige Namenswahl für Datenflüsse 

3. Eindeutige Bezeichnung der Prozesse (aller seiner Aktionen) 

8. MiniSpecs für alle nicht-verfeinerten Prozesse 



Zusammenfassung 

Konzepte 

• Hierarchisch angeordnete Datenflussdiagramme (DFDs) 

• Data Dictionary Einträge (DDs) 

• Mini-Spezifikationen (MiniSpecs) 

DFD 0: Verfeinerung des Kontextdiagramms 

• Prozess 0 wird in Teilprozesse zerlegt. 

• Datenflüsse werden ebenfalls verfeinert. 

• Speicher werden eingeführt. 

• Neue Datenflüsse zwischen Prozessen und mit Speichern werden 

eingetragen. 

• Schnittstellen und Speicher dürfen nicht verfeinert werden. 

DFD 1, ..., DFD 1.1, ..., DFD n.m 

• Jeder Prozess kann weiter zu einem neuen Diagramm verfeinert 

werden. 

• Anzahl der Prozesse pro Diagramm soll maximal 7 sein. 

• Ist ein Prozess ausreichend verstanden, dann Beschreibung durch 

MiniSpec. 



Zusammenfassung 

DD-Eintrag und Datenintegrität 

• Jeder Datenfluss und jeder Speicher wird im DD definiert. 

• Zusammenhang zwischen den Datenflüssen der DFDs über DD 

• Datenflüsse untergeordneter DFDs müssen im übergeordneten DFD 

unter gleichem Namen erscheinen oder dort Komponente eines DFD 

sein. Datenintegrität: Gültigkeit für alle DFDs. 

MiniSpec 

• Beschreibung eines nicht mehr verfeinerten Prozesses 

• Beschreibung, wie Eingabedatenflüsse in Ausgabedatenflüsse 

transformiert werden 

• Beschreibung durch Pseudocode, Entscheidungstabellen oder

Zusammenfassung ZA und PN Modellierung

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?