Strukturierte Analyse

[mandark666]

Wir sollen ein Referat halten über Strukturierte Analyse inklusive Übung zu Datenflussdiagramm.

Wie das so ist wenn der Lehrer die "Projekt"-Gruppen zusammenstellt sind es immerhin 2 von 5 Leuten die auch mitarbeiten.

Naja, auf jeden Fall hab ich schon ne zeitlang gegoogelt aber trotzdem kapier ich net so ganz was das überhaupt alles ist. Ich hasse Anw. *g*

Gehts da irgendwie drum, Datenflussdiagramme zu zeichnen, diese zu verfeinern und dann noch ein Data Dictionary zu schreiben? Und irgendein Kontextbaum gibts auch noch, da stehen die DFDs drin? Kann mir das mal einer in einfachen Worten erklären?

[Schachcomputerfreak]

Original geschrieben von mandark666

Wir sollen ein Referat halten über Strukturierte Analyse inklusive Übung zu Datenflussdiagramm.

Wie das so ist wenn der Lehrer die "Projekt"-Gruppen zusammenstellt sind es immerhin 2 von 5 Leuten die auch mitarbeiten.

Naja, auf jeden Fall hab ich schon ne zeitlang gegoogelt aber trotzdem kapier ich net so ganz was das überhaupt alles ist. Ich hasse Anw. *g*

Gehts da irgendwie drum, Datenflussdiagramme zu zeichnen, diese zu verfeinern und dann noch ein Data Dictionary zu schreiben? Und irgendein Kontextbaum gibts auch noch, da stehen die DFDs drin? Kann mir das mal einer in einfachen Worten erklären?

Also einen Überblick über Testverfahren gibt es hier:

http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-SWT-2003/63_2LE_14tw.pdf

und etwas ausführlicher hier:

http://ais.informatik.uni-leipzig.de/download/2003s_v_sqm/2003s_sqm_v_06.pdf

wobei hier die Testverfahren auch recht gut erklärt werden.

ein recht ausführliches Script (hat mir mal eine Klausur gerettet...) findet sich hier:

http://www.informatik.htw-dresden.de/~fritzsch/QSM/qsm_script.html

Das sollte eigentlich Deine Fragen beantworten.

[mandark666]

Ich glaub, Du verwechselst da was.

Hier mal paar Links:

http://www.iste.uni-stuttgart.de/se/teaching/courses/sest/Uebung4.pdf

www.techfak.uni-bielefeld.de/~shuewel/softwareentwicklung/handout_SAzusammenfassung.pdf

Die machen mich aber net wirklich schlauer. Ich weiß zwar ungefähr worum und wie es geht, aber im Endeffekt weiß ich eigentlich garnix.

[Schachcomputerfreak]

stimmt, ich hab das verwechselt. Sorry, mit der Art von Analysen hab ich leider auch nicht viel am Hut. Das geht schon mehr ins Projektmanagement rein. Aber vielleicht kann ja jemand anderes noch weiterhelfen.

[mandark666]

Ja, genau darum gehts, Software Engineering, Projektmanagement, der Quatsch halt, für mich ein Buch mit sieben Siegeln.

Aber in ANW kommt dieses Jahr die einzige Note von dieser Präsentation, also muss ich mich doch näher damit beschäftigen. :/

[just_me]

Na dann wollen wir mal schauen, ob wir den Quatsch nicht erklärt kriegen ...

Ich weiß zwar ungefähr worum und wie es geht, aber im Endeffekt weiß ich eigentlich garnix.

Wollen wir wetten, dass das Einzige, was du nicht weißt, eigentlich nur die Tatsache ist, dass du es bereits weißt?

Die strukturierte Analyse ist letztlich nichts anderes, als das, was du (fast) jeden Tag machst:

Angenommen du siehst einen Kartentrick. Zuerst denkst du "Yep, cool.". Sekunden später denkst du "Hääääää?", und noch ein paar Sekunden später schaust du sehr genau hin, wenn der Trick wiederholt wird.

Und je öfter der Zauberer den Trick wiederholt, desto mehr Details fallen dir auf. Du stellst fest, dass bestimmte Bewegungen Voraussetzung für andere Bewegungen sind, und dass die Karten auf eine definierte Art und Weise bewegt werden müssen damit der Trick gelingt. ...

Auch wenn dieser Vergleich etwas hinkt, ist er doch geeignet, zu zeigen, dass structured analysis "alltäglich" ist.

Nehmen wir mal an, du wolltest den Prozess einer Antragsbearbeitung beschreiben.

Zunächst funktioniert es scheinbar wie eine black box: Antrag rein - Ergebnis raus.

Die erste Verfeinerung schneidet die black box auf. Du stellst fest, dass mehrere Abteilungen mit der Bearbeitung des Antrags befasst sind --- mit anderen Worten, es fließen Daten zwischen ihnen hin (und her).

Der Einfachheit halber nimmt Abteilung 1 (Schnittstelle1) den Antrag (nebenläufige Datenquelle) vom Antragsteller (Datenquelle) entgegen, Abteilung 2 (Schnittstelle2) bearbeitet ihn und Abteilung 3 (Schnittstelle3) schickt das Ergebnis an den Antragsteller (Datensenke) zurück. (Geht der Antrag unterwegs verloren, wäre die Stelle ebenfalls eine Datensenke.)

Wir haben also aus einer großen black box drei kleinere gemacht --- und ein neues Problem: Wer genau ist eigentlich der "Antragsteller"? Was ist ein "Antrag"? Und was bedeutet "bearbeiten"?

Um das ein für alle Mal zu klären, baust du ein data dict auf. Es beinhaltet eindeutige Beschreibungen (Datendefinitionen). Der Antragsteller setzt sich aus Name + Vorname + Geschlecht + ... + n Attribute zusammen, der Antrag kombiniert Antragsteller + Summe + Datum, und bearbeiten meint Aktionen, wie "genehmigen" oder "ablehnen".

Die Darstellung bis hierher wäre ein nettes Kontextdiagramm, weil es die groben Zusammenhänge schon recht gut erläutert.

Wenn du die Schnittstelle2 detaillierter auflöst, wirst du feststellen, dass in der Abteilung 2 mehrere Leute hocken, die den Antrag jeweils teilweise bearbeiten. Hier nutzt man Datenflussdiagramme, um den Informationsfluss zu granulieren. Mitarbeiter 1 (Schnittstelle2.1) prüft beispielsweise, ob der Antrag fristgemäß abgegeben wurde. Dabei interessiert ihn aber ausschließlich Attribut "Datum" der Datenquelle "Antrag". Dieses vergleicht er mit einem vorgegebenen Datum aus einer Datenbank (Speicher). Mitarbeiter 2 (Schnittstelle2.2) prüft seinerseits lediglich, ob die Summe nicht zu hoch oder zu niedrig ist. Dazu bezieht er ebenfalls ausschließlich Detailinformationen aus dem Antrag.

Im Laufe des Zooms wirst du immer tiefer in die Details hineinblicken und immer detaillierter beschreiben, wie, wann, woher und wohin welche Informationen (Daten) fließen und was dort mit ihnen geschieht (Datenflussdiagramm).

Am Ende all deiner Bemühungen steht dann eine wunderschöne und sehr überschaubare Beschreibung (durchaus hochkomplexer) Vorgänge die insbesondere für das Qualitätsmanagement interessant ist.

Der Hierarchiebaum entsteht übrigens im wahrsten Sinne des Wortes von alleine, wenn du alle deine Diagramme geordnet aneinanderlegen würdest.

Oh, und ein paar weiter Quatsch-Dinger (MiniSpec, Qualitätssicherung, Informationsabgleich, etc.), gibt's da noch, aber die sind für einen ersten Überblick nicht so wichtig.

[mandark666]

Cool, Danke. das hört sich richtig gut an.

Aber ich stelle mir das Erstellen da doch recht kompliziert vor. Ok, ich mal Abt1 2 und 3 und dazu noch den Kunden auf ein Blatt Papier und mal da ein paar Linien dazwischen.

Dann nehm ich mir ein weiteres Blatt Papier und mal da Abt1 drauf, besser gesagt Mitarbeiter x y und z aus Abt1, ebenso verfahre ich mit Abt2 und 3.

Dann könnte ich ja auch noch Mitarbeiter x aus Abt1 auf ein weiteres Blatt Papier malen, besser gesagt was der so treibt, also Vorgang aus Posteingang holen, Stempel drauf und in Postausgang legen.

So kann ich mir das vorstellen?

Und im Data Dictionary schreibe ich die einzelnen sagen wir mal Instanzen (also "Abt1" oder "aus Postausgang holen") und beschreibe da ein wenig kompliziert (hab hier ein Blättchen "Data Dictionary und mBNF" und die Nackus-Naur-Form") auf was die einzelnen "Instanzen" bedeuten?

Und den Hierarchiebaum erstelle ich am Schluss und trage da die ganzen Blätter, die ich am Anfang mit Datenflussplänen zugepinselt habe, ein und verweise auf das Data Dictionary?

Sorry daß ich ein wenig wirr schreibe, aber mich haben gerade ein paar Geistesblitze durchflutet.

[just_me]

So kann ich mir das vorstellen?

Yep. Das ist schon der ganze Trick. Viel mehr steckt da (Leider oder Gott sei Dank?) nicht hinter. ...

Oops: Der Hierarchiebaum wächst normalerweise mit deinen Spezifikationen. Sonst verläufst du dich ganz schnell.

Ich meinte es eigentlich nur symbolisch --- obwohl du ihn durchaus auch erst zum Schluss erstellen KANNST.

[mandark666]

Achso, also also male ich den sozusagen nebenher?

Und wie kann ich mir das optisch vorstellen bzw gibts da eventuell auch Programme um sowas zu fabrizieren?

Edit:

Achja und was ist nun ein Kontextdiagramm? Ist das der Hierarchiebaum?

[just_me]

Die Funktion des Baumes ist es, deine Auflösung zu begrenzen. Sonst müsstest du es unendlich fortsetzen ...

Du "malst" ihn also nicht, sondern du "begrenzt" ihn, indem du seine Blätter durch MiniSpecs beschreibst.

Das Kontextdiagramm ist das oberste DFD. Das "nullte" Datenflussdiagramm heißt "Kontextdiagramm", weil es als einziges den gesamten Kontext (ZUsammenhang) darstellt.

[mandark666]

Achso.

Also mal ich mir erstmal ein Kontextdiagramm, wo beispielsweise Kunde und Firma draufsteht.

Dann überleg ich mir wie tief ich gehen will bzw wohin ich tiefergehen kann, zb bis Mitarbeiter X. Das werden dann die Minispecs?

Jetzt erstelle ich den Hierarchiebaum mit Hilfe dieser Minispecs. Dann noch die vers. DFDs und das Data Dictionary und fertig?

[just_me]

Also mal ich mir erstmal ein Kontextdiagramm, wo beispielsweise Kunde und Firma draufsteht.

Dann überleg ich mir wie tief ich gehen will bzw wohin ich tiefergehen kann, zb bis Mitarbeiter X. Das werden dann die Minispecs?

Yep.

Jetzt erstelle ich den Hierarchiebaum mit Hilfe dieser Minispecs.

MiniSpecs beschreiben nur die Blätter. Die "Äste" malst du mit den DFD.

Wenn du es so meinst: Yep.

[mandark666]

Soweit ok, aber ich dachte, auf dem Hierarchiebaum trage ich die verschiedenen DFDs ein? Und die DFDs baue ich wiederum aus den Minispecs die ich mir ausgedacht habe UND dem Hierarchiebaum.

Mal ein Beispiel:

Kontextdiagramm ist die Übersicht

Minispecs beschreiben die vielen verschiedenen Blätter die ich mir da "rausziehen" kann, also Abteilungen, Mitarbeiter, Vorgänge etc. Oder meinetwegen auch Eingabe, Speicherung, Bearbeitung, Ausgabe.

In Hierarchiebaum trage ich dann die Äste ein, also die verschiedenen Ebenen unterhalb des Kontextdiagrammes.

Und am Schluss erstelle ich noch dieses Data Dictionary.

Ich muss jetzt mal heim, wird so 20min dauern. Vielen Dank schonmal.

[just_me]

Dann würdest du quasi "das Pferd von hinten aufzäumen".

1. Kontextdiagramm (= Übersicht)

2. Rahmen/Auflösungstiefe abstecken (virtuell)

3. DFD + DD erstellen/malen/pflegen

4. Punkt 3 beliebig oft wiederholen

5. die entstandenen Blätter mit den MiniSpecs "festnageln"

Fertig. Naja, im Wesentlichen. Oder besser: Was die Erstellung betrifft.

[mandark666]

Wenn ich mir die Tiefe abstecke, dann hab ich ja eigentlich auch schon eine ungefähre Vorstellung der Minispecs.

Wo steckt da jetzt eigentlich der Hierarchiebaum? In Punkt 2?

Aber ich denke, ich habs jetzt halbwegs kapiert. Jetzt noch abklären, ob ich das alles wirklich allein präsentieren/erklären muss, und dann ist meine Anw-Note vielleicht doch noch gerettet.

Dir auf jeden Fall schonmal :hodata

[just_me]

Wenn ich mir die Tiefe abstecke, dann hab ich ja eigentlich auch schon eine ungefähre Vorstellung der Minispecs.

Pauschal? Yep.

Aber das hängt von vielen Faktoren ab, die nicht immer einfach kontrollierbar sind.

Wo steckt da jetzt eigentlich der Hierarchiebaum? In Punkt 2?

Das ist ungefähr vergleichbar mit dem "Malen nach Zahlen" für Kinder. Punkt 2 stellt dabei die Vorlage dar, und Punkt 3 repräsentiert die Farben. Beide zusammen machen den Baum dann "sichtbar".

Aber der Hierarchiebaum ist mehr eine Kontrollstruktur als von grafischer Relevanz. Mit seiner Hilfe muss es möglich sein, sich quasi an einem Ast entlanghangelnd, vom Groben bis zu hochauflösenden Details zu gelangen, ohne dass der Datenfluss (beispielsweise beim Übergang zwischen den einzelnen DFD) jemals "hakt" oder "nicht nachvollziehbar" wird. Ich muss also in der Lage sein, den Finger auf ein DFD Level1 zu legen, und dort beginnend, ohne den Finger anheben zu müssen, dem Datenfluss folgen zu können, bis ich ein Blatt (auf Level xx) erreiche.

Lege daher bitte nicht allzu gesteigerten Wert darauf, ihn nun "grafisch entdecken" zu müssen.

[mandark666]

Nun denn, dann wollen wir es mal bei Deinen wirklich guten Ausführungen belassen. Du solltest Lehrer werden. :uli