Structured Analysis (SA) - Strukturierte Analyse (SA).ppt

enthält auch: Data Flow Diagram (DFD) - Datenflußdiagramm (DFD)

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

Semantische Regeln / Namensgebung

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

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:

Hierarchiekonzept

Analyseschritte nach DeMarco

Kritikpunkte bezüglich der konventionellen Vorgehensweise:

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:

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:

Essentielle Zerlegung

Bei der essentiellen Zerlegung wird ein Systemmodell entwickelt, indem

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

Hierarchiekonzept

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:

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

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 Systemstruktu

Schalenförmige Systemstruktur

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 :

Leitfaden und Fallbeispiel zur essentiellen Systemanalyse

Um die essentielle Systemanalyse erfolgreich abzuschließen sind die folgenden Arbeitsschritte sind erforderlich:

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:

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

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

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

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

Erweitertes Kontextdiagramm

DFD um Verwaltungsaktivitäten ergänzen

DFD-Rohentwurf mit essentiellen Aktivitäten

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

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:

Basis für diese Beschreibung ist ein Vortrag von U. Bechstein, SBS.