Structured Analysis (SA) - Strukturierte Analyse (SA).ppt
enthält auch: Data Flow Diagram (DFD) - Datenflußdiagramm (DFD)
- Statische Elemente
- Dynamische Elemente
- Datenstrukturierung
- Hierarchiekonzept / Top-Down-Zerlegung
- Vorgehensweise nach DeMarco
- Weiterentwicklung zur essentiellen Systemanalyse
- Ziel der essentiellen Systemanalyse
- Art der zu untersuchenden Systeme
- Perfekte Technologie
- Essenz eines Systems
- Essentielle Zerlegung
- Ereignisorientierte Zerlegung des Systems in essentielle Aktivitäten
- Objektorientierte Zerlegung des essentiellen Speichers
- Ergebnis der essentiellen Zerlegung / weiteres Vorgehen
- Bestandteile eines vollständigen essentiellen Modells
- Vorteile der essentiellen Systemanalyse
- Auswirkungen der nicht-perfekten Technologie auf konkrete Systeme
- Leitfaden und Fallbeispiel zur essentiellen Systemanalyse
- Ziele des Systems festlegen
- Ereignistabelle erstellen
- Zusammensetzung der Auslöser und Reaktionen im Data Dictionary
- Grundlegende Aktivitäten und erforderliche Speicher in Datenflußdiagramm des Zielsystems eintragen
- Objektorientierte Zerlegung des essentiellen Speichers
- Ereignistabelle vervollständigen
- Data Dictionary vervollständigen
- Kontextdiagramm vervollständigen
- DFD um Verwaltungsaktivitäten ergänzen
- Verdichtung des DFD nach oben
- Detaillierung einzelner Prozesse mit weiteren DFD
- Mini-Spezifikationen für die nicht weiter zerlegten Prozesse erstellen
- Datenflußdiagramme nach Gane / Sarson
Structured Analysis (SA) ist eine Methode, welche die Datenflüsse in den Vordergrund stellt. SA wurde in den 70-er Jahren von Tom DeMarco und von C.Gane / T.Sarson formuliert, und von der Fa. Yourdan international verbreitet. Die von Stephen M. McMenamin / John F. Palmer vorgenommene Erweiterung der SA um eine Analysestrategie wird auch als "essentielle Systemanalyse" bezeichnet. Sowohl Paul Ward /Stephen J. Mellor als auch D. J. Hatley / I. A. Pirbhai erweiterten SA für die Spezifikation von Echtzeitsystemen. 1989 faßte Ed Yourdan die SA-Erweiterungen in einem Buch zusammen.
Mit SA wird ein System vor allem durch hierarchisch angeordnete Datenflußdiagramme (DFDs; "Bubble Charts") grafisch beschrieben. Prozesse werden solange zerlegt, bis für die Teilprozesse knappe Minispezifikationen (MiniSpec) erstellt werden können. Die Datenflüsse und Datenspeicher werden im Datenkatalog (Data Dictionary) detailliert beschrieben.
Statische Elemente
Die Notation von DeMarco benutzt folgende 4 grafische Elemente:
| Element | grafische Darstellung |
|---|---|
| Terminator (Datenquelle oder Datensenke) |
 |
| Datenfluß |  |
| Prozeß |  |
| Datenspeicher |  |
Grafische Notation bei DeMarco
Syntaktische Regeln
- Das Kontextdiagramm beschreibt die Schnittstellen des Systems zur Umgebung und enthä nur einen einzigen Prozeß für das gesamte Zielsystem.
- Terminatoren (Datenquellen und -senken) werden nur in das Kontextdiagramm eingetragen.
- Das Kontextdiagramm enthä keine Datenspeicher.
- Keine Beschriftung der Datenflüsse von und zu Datenspeichern, da der Typ der fließenden Daten aus dem Dateinamen abgeleitet werden kann (Ausnahme: vom Prozeß werden nicht alle Attribute des Datenspeichers benutzt).
Semantische Regeln / Namensgebung
- Datenfluß-Namen:
Substantiv, welches den gesamten Datenfluß und nicht nur die Hauptkomponente beschreibt; darf zwar keine Verarbeitung beschreiben, u. U. jedoch den Verarbeitungszustand. DeMarco empfiehlt, erst alle Datenflüsse zu benennen, bevor die Prozesse benannt werden. - Prozeß-Namen:
Möglichst aussagekräftige Namen verwenden (also nicht "Eingabedaten verarbeiten"). Name besteht in der Regel aus Substantiv und Verb; das Substantiv bezeichnet normalerweise das vom Prozeß erzeugte Ergebnis. - Speicher-Namen:
Beschreibendes Substantiv (in der Regel im Singular - z. B. "Auftrag", "Kunde", "Adresse", "Artikel"; wenn aber gleichnamige Datenflüsse vorhanden, dann für den Speicher-Namen Plural verwenden).
Dynamische Elemente
Die Prozesse, die nicht weiter verfeinert werden, werden mittels Minispezifikationen (MiniSpecs) beschrieben. Die MiniSpecs beschreiben den Kontrollfluß in strukturierter Sprache (Faustregel: max. 1 DIN A4 -Seite).
 |
Für Theatervorstellung mit Aufführung=gewünschte Aufführung und Vorstellungsort=gewünschter Vorstellungsort und Vorstellungstermin=gewünschter Vorstellungstermin wenn in gewünschter Platzkategorie freier Platz vorhanden Reihen-Nr+Sitz-Nr+Theaterkartenpreis+Vorverkaufsgebühr ausgeben sonst falls beide Platzkategorien ausverkauft "Vorstellung ist ausverkauft" ausgeben falls nur gewünschte Platzkategorie ausverkauft " Platzkategorie ist ausverkauft" ausgeben wenn nicht gefunden "gewünschte Vorstellung findet nicht statt" ausgeben |
Datenstrukturierung
Jeder Datenfluß und jeder Datenspeicher wird im Data Dictionary in seiner Zusammensetzung beschrieben.
Data Dictionary gelten folgende syntaktische Regeln:
| Symbol | Bedeutung | Beispiel |
|---|---|---|
| = | Äquivalenz | A=B + C |
| + | Sequenz, keine implizite Ordnung | A=A1 + A2 + A3 |
| [ | ] | Alternative | A=[ B | C ] |
| { } | Iteration | A={ B } |
| m{ }n | Iteration mit Grenzen | A=1{ B }5 |
| ( ) | Option, 0 oder 1 mal vorhanden | A=B + (C) |
| * * | Kommentar | A=B + C *Kommentar* |
Symbole für DD-Einträge
|
Platzkategorie Platz Bestuhlung |
=[ Rang | Parkett ] =Platzkategorie + Reihen-Nr. + Sitz-Nr. Bestuhlung={ Vorstellungsort + {Platz} } * für alle Plätze an allen Vorstellungsorten * |
Hierarchiekonzept / Top-Down-Zerlegung
Ausgehend von dem Kontextdiagramm (enthä nur einen Prozeß; dieser trägt die Nummer 0) wird jeder Prozeß top-down solange weiter zerlegt und in einem eigenen DFD beschrieben, bis der Prozeß kurz und prägnant mit einer MiniSpec beschrieben werden kann. Hierbei gilt folgendes Numerierungssystem:
Hierarchiekonzept
Die Prozeßnummer hat die DFD-Nummer als Präfix; in der Kurzform kann dieser Präfix entfallen.
Parallel zur Verfeinerung der Prozesse werden auch die Datenflüsse verfeinert. Der Zusammenhang zwischen den Datenflüssen der einzelnen Diagramme ergibt sich über die Data Dictionary-Einträge. Die Datenflüsse eines untergeordneten DFD sind entweder mit dem entsprechenden Datenflußnamen des Eltern-DFD identisch, oder aber es handelt sich um eine Teilkomponente dieses Datenflusses.
Vorgehensweise nach DeMarco
Nach De Marco erfolgt die Systemanalyse in folgenden 4 Analyseschritten:
- Erstellung des physischen IST-Modells
Erst auf Basis der physischen Details des IST-Modells kann die Essenz herausgearbeitet werden; keine Abstraktion im luftleeren Raum möglich. - Erstellung des logischen IST-Modells
Implementierungsdetails des bestehenden Systems werden entfernt; keine Unterscheidung zwischen manuellen und automatisierten Vorgängen. - Erstellung des logischen SOLL-Modells
Berücksichtigt die Anforderungen an das zukünftige System (DeMarco spricht hier von "Charter for Change"). - Erstellung des physischen SOLL-Modells
In diesem Schritt möchte DeMarco nur den erforderlichen Mindestumfang an physischer Festlegung vornehmen (z.B. Festlegung der Automatisierungsgrenze des Zielsystems; u.U. auch Performance-Anforderungen).
Analyseschritte nach DeMarco
Kritikpunkte bezüglich der konventionellen Vorgehensweise:
- Viele Projekte blieben in der "physikalischen Schlammgrube" stecken (Erhebung überflüssiger physikalischer Details des IST-Modells - Informationen, die nachher weggeworfen werden).
- Ein Festbeißen an den Fehlern des IST-Modells vergiftet Projekt-Klima.
- Häufig existieren schon konkrete Anforderungen an ein neues System.
- Es handelt sich um eine reine Darstellungstechnik ohne Leitfaden zur Modellentwicklung.
Weiterentwicklung zur essentiellen Systemanalyse
Die Weiterentwicklung zur essentiellen Systemanalyse erfolgte durch McMenamin und Palmer.
Ziel der essentiellen Systemanalyse
Ziel ist eine Vorgehensweise zum Aufspüren und Modellieren der wahren, logischen, essentiellen Systemanforderungen (Konzentration auf logisches Soll, die Vorphasen sind nur ein bedauerlicher aber notwendiger Umweg zum Ziel).
Art der zu untersuchenden Systeme
Bei den zu untersuchenden Systemen handelt es sich um interaktive Systeme, die mit geplanten Reaktionen auf externe und zeitliche Ereignisse antworten.
In einer Ereignisliste werden alle relevanten Ereignisse, sowie der zugehörige ereignisabhängige Eingabefluß (Auslöser) und Ausgabefluß (Reaktion) beschrieben.
Diese Datenflüsse des Zielsystems von und zu den Umgebungskomponenten (Terminatoren) werden im Kontextdiagramm dargestellt.
Perfekte Technologie
Das Gedankenmodell der perfekten Technologie erleichtert eine implementierungsunabhängige Sichtweise:
- Prozessor (Rechner oder Mensch):
unendliche Verarbeitungsleistung, kann alles, kostet nichts, macht keine Fehler - Speicher:
unendliche Speicherkapazität, sofortiger Zugriff, kostet nichts
Essenz eines Systems
Bei der Essenz eines Systems handelt es sich um jene Eigenschaften, die auch dann vorhanden sind, wenn es mit perfekter Technologie implementiert wäre.
Die Essenz eines Systems besteht aus:
- Grundlegenden Aktivitäten (begründen die Existenzberechtigung des Systems)
- Essentielle Speicher (puffern Daten bis zum Verwendungszeitpunkt durch grundlegende Aktivitäten)
- Verwaltungsaktivitäten (besorgen und aktualisieren Daten)
Essentielle Zerlegung
Bei der essentiellen Zerlegung wird ein Systemmodell entwickelt, indem
- eine ereignisorientierte Zerlegung des Systems in essentielle Aktivitäten und
- eine objektorientierte Zerlegung des essentiellen Speichers
vorgenommen wird.
Ereignisorientierte Zerlegung des Systems in essentielle Aktivitäten
Jedem einzelnen Ereignis einer Ereignisliste wird ein Prozeß zugeordnet; dieser Prozeß (essentielle Aktivität) faßt all jene Aktionen zusammen, die das System als Antwort auf dieses Ereignis ausführen würde, wenn es mit perfekter Technologie implementiert wäre. Nach Ausführung dieser Aktionen steht das System still bis ein neues Ereignis eintrifft.
Zeitliche Ereignisse sind genauer zu analysieren; sie werden häufig nur deshalb formuliert, weil eine Realisierung mit nicht perfekter Technologie unterstellt wird. Dies muß zumindest transparent werden.
Verkauf von Waren und Nachbestellung dieser Waren
Ermittlung der essentiellen Aktivitäten
Bei Variante 1 wird eine zyklische Bestandsprüfung unterstellt (also ein zeitliches Ereignis). Damit wird jedoch zum falschen Zeitpunkt bestellt. Der richtige Zeitpunkt wäre dann, wenn durch die Verkaufsmenge der Meldebestand erreicht bzw. unterschritten wird (Variante 2).
Objektorientierte Zerlegung des essentiellen Speichers
Theoretisch sind 2 extreme Speicher-Zerlegungsstrategien denkbar:
- alle Datenelemente in 1 Speicher
- pro Datenelement 1 Speicher
Bei der objektorientierten Zerlegung des essentiellen Speichers wird so zerlegt, dass es zu jedem (realen oder abstrakten) Objekt der Systemumgebung, über das das System sich Daten merken muß, genau einen Speicher gibt ( z.B. Auftrag, Kunde, Artikel, ...). Diese Zerlegung des essentiellen Speichers entspricht der Entity-Relationship-Methode und hat ein redundanzfreies Modell des essentiellen Speichers zum Ziel.
Ergebnis der essentiellen Zerlegung / weiteres Vorgehen
Die essentielle Zerlegung liefert einen ersten DFD-Rohentwurf und enthä nur essentielle Aktivitäten, welche über Speicher miteinander kommunizieren. Dieser Rohentwurf enthä normalerweise bereits zu viele Prozesse um noch gut verständlich zu sein.
Andererseits sind viele essentielle Aktivitäten noch zu komplex und müssen deshalb in weitere Teilprozesse zerlegt werden (erst diese Datenflüsse kommunizieren über Datenflüsse miteinander!).
In Richtung der übergeordneten Hierarchieebenen muß eine Verdichtung der essentiellen Aktivitäten erfolgen. Hierbei sind inhaltlich verwandte Prozesse zusammen―zufassen und gemeinsam genutzte Speicher zu kapseln.
Bestandteile eines vollständigen essentiellen Modells
Ein vollständiges essentielles Modell gliedert sich in
- Umgebungsmodell, bestehend aus
- Zielformulierung,
- Kontextdiagramm und
- Ereignisliste
- Internes Modell des Zielsystems (Verhaltensmodell / Funktionsmodell),
bestehend aus
- DFDs (außer Kontext),
- Entity-Relationship-Diagramm,
- Data Dictionary und
- MiniSpecs
Vorteile der essentiellen Systemanalyse
Das zu entwickende System besitzt eine schalenförmige Systemstruktur. Ausgehend vom Gedankenmodell der perfekten Technologie modelliert die essentielle Systemanalyse den logischen Kern des Systems. Das zu entwickelnde System wird dadurch zukunftssicherer, indem technologieabhängige Systemteile in die Randbereiche des Systems ausgegliedert werden.
Schalenförmige Systemstruktur
- spontane Hülle:
Keine geplanten Reaktionen; Entlastung des Systemkerns. - Infrastruktur:
Anpassungsaufgabe: realisiert die Kommunikation zwischen Systemkern und Umgebung sowie zwischen Subsystemen (z.B. Transportfunktionen, Entgegennahme von Aufträgen, postali-scher Versand, Bündelung der Ausgaben, Einscannen von Dokumente für anschließende Bearbeitung, Formatumwandlungen). - Administration:
Aufgabe: Prüfung, Qualitätssicherung und Koordination (z.B. Fehler der Umgebung und eigene Fehler erkennen und beseitigen; interne Koordination und Kontrolle der Systemprozesse).
Infrastruktur und Administrationsaktivitäten kompensieren die nicht perfekte Technologie (Prozessoren können nicht alles und machen Fehler; kein sofortiger Zugriff auf relevante Daten möglich).
Auswirkungen der nicht-perfekten Technologie auf konkrete Systeme
Durch den Einsatz von nicht-perfekter Technologie wird die Essenz des Systems verschleiert. Dies muß bei der IST-Analyse bestehender Systeme berücksichtigt werden. Die Auswirkungen von nicht-perfekter Technologie äußern sich in :
- Zerstückelung:
Aktivität wird auf viele Prozessoren verteilt. - Arbeitsteilung :
Erschwert Erkennen des Gesamtzusammenhangs, aufwendige Koordination und Fehlerprüfung erforderlich. - Redundanz:
Aktivitäten müssen unnötigerweise redundante Daten verarbeiten und pflegen; auch redundante Prozessoren erforderlich (z.B. Reserverechner). - Zusatzkomponenten:
Infrastruktur- und Administrationsaufgaben - Umständlichkeit
Such- und Sortiervorgänge, Speichern von Zwischenergebnissen - Konglomerat
Nicht ausgelasteter Prozessor übernimmt zusätzliche Aktivität. - Systemgröße
Nur wenige - wenn überhaupt - haben noch den Gesamtüberblick über das gesamte System.
Leitfaden und Fallbeispiel zur essentiellen Systemanalyse
Um die essentielle Systemanalyse erfolgreich abzuschließen sind die folgenden Arbeitsschritte sind erforderlich:
- Ziele des Systems festlegen
- Ereignistabelle erstellen
- Kontext-Diagramm erstellen
- Zusammensetzung der Auslöser und Reaktionen im Data Dictionary beschreiben
- Grundlegende Aktivitäten und erforderliche Speicher in Datenflußdiagramm des Zielsystems eintragen
- Objektorientierte Zerlegung des essentiellen Speichers
- Ereignistabelle vervollständigen
- Data Dictionary vervollständigen
- Kontextdiagramm vervollständigen
- DFD um Verwaltungsaktivitäten ergänzen
- Verdichtung des DFD nach oben
- Detaillierung einzelner Prozesse mit weiteren DFD
- MiniSpecs für die nicht weiter zerlegten Prozesse erstellen
Zu jedem dieser Schritte gibt es Checklistenpunkte, ergänzt um Beispiele eines Vorverkaufssystems für Theaterkarten.
|
Annahmen: Das Theater besitzt mehrere Vorstellungsorte (z.B. Probebühne); an jedem Vorstellungsort gibt es die Platzkategorie "Parkett" und "Rang" mit voneinander abweichenden Preisen. |
Ziele des Systems festlegen
Das Vorverkaufssystem soll:
- Auskunft über laufende Aufführungen erteilen.
Zu einer bestimmten Aufführung sind die nicht ausverkauften Termine anzugeben; für diese Termine ist eine Beschreibung der freien Plätze unter Angabe des jeweiligen Preises zu geben. - Verkauf von Theaterkarten abwickeln
Gegen Bezahlung des eigentlichen Kartenpreises zzgl. der Vorverkaufsgebühr erhä der Kunde eine Theaterkarte für einen bestimmten Platz in einer bestimmten Theatervorstellung.
Mit dem Vorverkauf der Theaterkarten sind noch weitere Tätigkeiten verbunden, wie z. B. nach Abschluß des Vorverkaufs die Mitteilung der Vorverkaufsbelegung an das Theater, z.B. für die Theaterabendkasse und zu Vorverkaufszwecken.
Ereignistabelle erstellen
Die grundlegenden Anforderungen werden in eine Ereignistabelle eingetragen. Bei diesen Ereignissen handelt es sich um Antwortanforderungen der Umgebung an des Zielsystem; sowohl auf externe, als auch auf zeitliche Ereignisse muß reagiert werden.
Im vorliegenden Beispiel wird vereinfachend davon ausgegangen, dass der Vorverkauf am Vorabend endet, und zu diesem Zeitpunkt auch die Mitteilung über die Vorverkaufsbelegung (Belegungs-Info) an das Theater erfolgt.
| Nr. | Ereignis | Auslöser | Reaktion |
|---|---|---|---|
| 1 | Kunde wünscht Kartenauskunft | Kartenanfrage | Kartenauskunft |
| 2 | Kunde wünscht Theaterkarte | Kartenbestellung | Theaterkarte |
| 3 | Vorverkaufsende für Vorstellung | (zeitl. Ereignis) | Belegungs-Info |
Erste Fassung der Ereignistabelle
Beim Erstellen der Ereignistabelle ist zu prüfen, inwieweit auch Ausnahmezustände zu berücksichtigen sind. Zwar wird für das Zielsystem zunächst die perfekte Technologie unterstellt.Trotzdem muß das Zielsystem auf die Fehler der Umgebung reagieren. Derartige Ausnahmezustände könnten im vorliegenden Fall z. B. Umtausch, Rückgabe und Verlust der Theaterkarte sein oder aber auch der Ausfall einer Theatervorstellung. Aus Vereinfachungsgründen bleiben diese Ereignisse im weiteren unberücksichtigt.
Kontext-Diagramm erstellen
Erste Fassung des Kontextdiagramms
Zusammensetzung der Auslöser und Reaktionen im Data Dictionary beschreiben
| Kartenanfrage | =Theatervorstellung + Platzkategorie * Frage nach freiem Platz zu bestimmter Vorstellung* |
| Kartenauskunft | =[" Vorstellung ausverkauft " | "Platzkategorie ist ausverkauft" | Platz + Theaterkartenpreis + Vorverkaufsgebühr] |
| Kartenbestellung | =Theatervorstellung + Platz + Zahlung *des Theaterkartenpreises und der Vorverkaufsgebühr * |
| Platz | =Theatervorstellung + Platz * Anrecht auf bestimmten Sitzplatz * |
| Theaterkarte | =Platzkategorie + Reihen-Nr. + Sitz-Nr. |
| Platzkategorie | =[ Rang | Parkett ] |
| Theatervorstellung | =Aufführung + Vorstellungsort + Vorstellungstermin |
| Aufführung | =Titel + Regisseur |
| Vorstellungstermin | =Jahr + Monat + Tag + Stunde + Minute |
| Belegungs-Info | =Theatervorstellung + {Platz + Belegungsstatus} |
| Belegungsstatus | =[ frei | belegt ] |
Grundlegende Aktivitäten und erforderliche Speicher in Datenflußdiagramm des Zielsystems eintragen
Erster Entwurf für DFD 0
Mit "Belegung" wird ein Datenspeicher eingeführt, welcher vorstellungsrelevante Daten zusammenfaßt.
| Belegung | ={ Theatervorstellung + {Platz + Belegungsstatus} } |
Objektorientierte Zerlegung des essentiellen Speichers
Denkbar wäre z. B. eine Zerlegung des essentiellen Speichers in folgende Objekte
- Spielplan (mit n Aufführungen)
- Aufführung (mit n Theatervorstellungen; denkbare beschreibende Attribute: Länge des Stücks, Bühnenbildner, Schauspieler, ...)
- Theatervorstellung
- Veranstaltungsort /Theater (denkbare beschreibende Attribute: Adresse, Buslinie, Eignung für Rollstuhlfahrer, Tel.-Nr., ...)
- Preisliste (Preis abhängig von Platzkategorie, u. U. auch vorstellungsspezifisch)
- Bestuhlung (denkbare beschreibende Attribute: räumliche Anordnung, Beinfreiheit)
Eine objektorientierte Zerlegung des Speichers sichert eine größere Flexibilität hinsichtlich zukünftiger Systemerweiterungen (z. B. erweiterte Auskunftsfunktionen).
Im vorliegenden Beispiel werden die Objekte Spielplan, Aufführung, Theater, Bestuhlung und Preisliste betrachtet; der Kunde bleibt für das System anonym.
Ereignistabelle vervollständigen
Der Lebenszyklus aller erforderlichen Daten ist zu analysieren.
Das Vorverkaufs-System muß die Daten von den stattfindenden Theatervorstellungen erhalten. Außerdem muß ein aktueller Bestuhlungsplan der Vorstellungsorte vorliegen. Der Theaterkartenpreis für die einzelnen Platzkategorien in den jeweiligen Vorstellungsorten muß bekannt sein (Preisliste). Für jedes Theater sollten auch allgemeine Informationen (wie z.B. Adresse, Erreichbarkeit mit öffentlichen Nahverkehr, ...) verfügbar sein.
Diese erforderlichen Datenflüsse sind in die Ereignistabelle aufzunehmen und müssen im Data Dictionary beschrieben und im Kontextdiagramm dargestellt werden. Anschließend sind im DFD die entsprechenden Verwaltungsaktivitäten zu ergänzen.
| Nr. | Ereignis | Auslöser | Reaktion |
|---|---|---|---|
| 1 | Kunde wünscht Kartenauskunft | Kartenanfrage | Kartenauskunft |
| 2 | Kunde wünscht Theaterkarte | Kartenbestellung | Theaterkarte |
| 3 | Vorverkaufsende für Vorstellung | (zeitl. Ereignis) | Belegungs-Info |
| 4 | Theater gibt Spielplan bekannt | Spielplan | - |
| 5 | Theater ändert Spielplan | Spielplanänderung | - |
| 6 | Theater gibt Aufführungsinfo | Aufführungsinfo | - |
| 7 | Theater gibt Theaterinfo | Theaterinfo | - |
| 8 | Theater ändert Preisliste | Preisliste | - |
| 9 | Theater schickt Bestuhlungsplan | Bestuhlungsplan | - |
Erweiterte Ereignistabelle
Data Dictionary vervollständigen
| Spielplan | ={Theatervorstellung} * alle Theatervorstellungen einer Saison * |
| Spielplanänderung | =Theatervorstellung *alter Ort und alter Termin * + Theatervorstellung * neuer Ort und neuer Termin * |
| Aufführungsinfo | =Titel + Regisseur + Stücklänge |
| Stücklänge | =* Spieldauer plus Pausendauer in Minuten * |
| Theaterinfo | =Vorstellungsort + Vorstellungsadresse + Buslinie |
| Bestuhlung | =Datum + {Vorstellungsort + {Platz} } * alle Plätze an allen Vorstellungsorten * |
| Preisliste | =Datum + {Vorstellungsort + {Platzkategorie + Theaterkartenpreis} * Theaterkartenpreise für die beiden Platzkategorien an allen Vorstellungsorten * |
Kontextdiagramm vervollständigen
Erweitertes Kontextdiagramm
DFD um Verwaltungsaktivitäten ergänzen
DFD-Rohentwurf mit essentiellen Aktivitäten
Verdichtung des DFD nach oben
Bei realitätsnahen Aufgabenstellungen ist die Anzahl der essentiellen Aktivitäten noch wesentlich größer als im vorliegenden Fall. Dann muß eine Verdichtung nach oben erfolgen. Für das Vorverkaufssystem werden deshalb beispielhaft die Verwaltungsaktivitäten zusammengefaßt. In der Praxis sollten beispielsweise noch einzelne Speicher gekapselt werden; über zusätzliche Data-Hiding-Prozesse würden dann fremde Prozesse auf diese Speicher zugreifen.
DFD 0 des Vorverkaufsystems
Detaillierung einzelner Prozesse mit weiteren DFD
Komplexe Prozesse werden in weitere Teilprozesse zerlegt und mit DFDs beschrieben. Die Kartenauskunft z.B. deckt nur einen Teilbereich der möglichen Auskunftsfunktionen ab (z.B. Spielplanauskunft, Aufführungsauskunft, Vorstellungsortauskunft, Bestuhlungsauskunft). Falls die anderen Auskunftsfunktionen nicht in der spontanen Hülle des Systems realisiert werden und evtl. sogar automatisiert werden sollen, dann müßte z.B. der Auskunftsprozeß weiter zerlegt werden.
Mini-Spezifikationen für die nicht weiter zerlegten Prozesse erstellen
Die Prozesse werden in strukturierter Sprache spezifiziert. Für den Prozeß 1 "Kartenauskunft erteilen"könnte dies z. B. folgendermaßen aussehen:
Für Theatervorstellung
mit
Aufführung=gewünschte Aufführung
und
Vorstellungsort=gewünschter Vorstellungsort
und
Vorstellungstermin=gewünschter Vorstellungstermin
wenn in gewünschter Platzkategorie freier Platz vorhanden
Reihen-Nr + Sitz-Nr + Theaterkartenpreis
+ Vorverkaufsgebühr ausgeben
sonst
falls beide Platzkategorien ausverkauft
"Vorstellung ist ausverkauft" ausgeben
falls nur gewünschte Platzkategorie ausverkauft
" Platzkategorie ist ausverkauft" ausgeben
wenn nicht gefunden
"gewünschte Vorstellung findet nicht
statt" ausgeben
Datenflußdiagramme nach Gane / Sarson
Formale Unterschiede der Gane/Sarson-Notation gegenüber der Yourdan/DeMarco-Notation
| Element | Gane / Sarson | Yourdan / DeMarco |
|---|---|---|
| Terminator |  |
 |
| Datenfluß |  |
 |
| Speicher |  |
 |
| Prozeß |  |
 |
Gane/Sarson- und Yourdan/DeMarco-Notation im Vergleich
Inhaltliche Unterschiede der Gane/Sarson-Notation gegenüber der Yourdan/DeMarco-Notation
Neben den eher kosmetischen Unterschieden weichen Gane/Sarson-DFDs von Yourdan/DeMarco-DFDs vor allem in folgenden Punkten ab:
- Bei Gane/Sarson unterstützt eine modifizierte Ebenenbildung die Vernachlässigung von Ausnahmesituationen (z.B. Storno einer Bestellung) auf höheren Ebenen. Zusätzliche Datenflüsse und Prozesse, die in den Detaildiagrammen zum erstenmal auftauchen werden mit einem X" markiert.
- Während das Yourdan/DeMarco - Lager vorschlägt, die Prozeßanzahl auf 7 +/- 2 zu begrenzen, akzeptieren Gane/Sarson auch 100 Prozesse in einem Datenflußdiagramm.
Basis für diese Beschreibung ist ein Vortrag von U. Bechstein, SBS.