Modellierung betriebswirtschaftlicher Problemstellungen auf Basis der Strukturierten Analyse

Inhalt

1 Relevanz der Strukturierten Analyse

2 Vorgehensweise und Konzepte zur Modellerstellung
2.1 Top-down-Methode
2.2 Datenflussdiagramm
2.3 Data Dictionary
2.4 Pseudo-Code
2.5 Entscheidungstabellen und Entscheidungsbäume
2.6 Entity-Relationship-Modell

3 Methodik der Strukturierten Analyse
3.1 Hierarchische Vorgehensweise
3.1.1 Kontextdiagramm
3.1.2 Funktionale Dekomposition
3.1.3 Data Dictionary
3.1.4 Prozessbeschreibung
3.2 Schritte zum Modell
3.3 Überprüfung entwickelter Modelle
3.4 Werkzeugbasierte Modellierung
3.5 Vor- und Nachteile

4 Resümee und Ausblick

Quellenverzeichnis

„Des Menschen größte Fehler sind Ungeduld, das vorschnelle Verwerfen ei­ner Methode, das irrtümliche Festhalten an einem Irrglauben.“

Franz Kafka

1 Relevanz der Strukturierten Analyse

In seinem Buch „Structured analysis and system specification“ hat Demarco das We­sen der Systemanalyse treffend zusammengefasst. Er schreibt, dass Systemana­lyse frustrierend sowie voll von komplexen zwischenmenschlichen Bezie­hungen, vage und schwierig ist. Kurz gesagt, sie ist faszinierend. Ist man erst einmal in­fiziert, werden die althergebrachten, einfachen Freuden der Systemanalyse nie wie­der genü­gen [DEMA78, S. 6]. Die Bedeutung und Richtigkeit einer solchen Aussage wird in vorliegender Arbeit deutlich.

Ein System, im Sinne der Strukturierten Analyse (SA), repräsentiert eine Menge von Prozessen, welche manuell oder automatisiert sein können und die zur Erreichung eines bestimmten Zieles erforderlich sind [DEMA78, S. 60]. Bei der Analyse muss die Systemspezifi­kation die wahren Anforderungen, d. h. alle Eigen­schaften und Fä­higkeiten, die ein System unabhängig von der Implementierung zwingend er­füllen muss, enthalten. Die Spezifikation ist mangelhaft, wenn falsche, wie bspw. irrele­vante Eigenschaften oder An­forderun­gen, welche nur für eine bestimmte Technolo­gie benötigt werden, bzw. nicht alle er­forderlichen An­forderungen identifiziert sind. Die vermeidbaren Fol­gen sind verheerend: hohe Kosten, Unzuverlässigkeit sowie schwer wart- und er­weiter­bare Systeme. Oft erfassen Analytiker mehr Anforderun­gen als notwendig. Dies führt zu schlecht lesbaren Analysen und bremst den Projekt­fort­schritt [MCME88, S. 3-9]. Ein Ansatz zur Vermeidung solcher Probleme stellt die in dieser Arbeit dis­kutierte SA dar.

Die SA wurde in den siebziger Jahren von DeMarco entwickelt. Er beschreibt diese als eine funktionsorientierte Methode zur Definition von Systemanforde­run­gen, wel­che zu einem hierarchischen Modell führt. Die Darstellung erfolgt in gra­phi­scher Form verbunden mit beschreibenden Textelementen. Grundidee ist, dass die Basis­kon­zepte Daten­flussdiagramm, Data Dictionary, Entschei­dungsta­bellen bzw. -bäume und Pseudo-Code in geeigneter Weise zu einem Gesamtkonzept kombiniert werden [DEMA78, S. 16]. Dadurch können die einzelnen Bausteine der Spezifikation unab­hängig von einander bearbeitet und gelesen werden. Durch die Reduktion von Re­dundanzen ist es möglich, veränderte Benutzeranforderung an meist nur einer Stelle pflegen zu müssen [YOUR92, S. 147].

Hauptziel der SA ist den Prozess der Systementwicklung zu strukturieren und so­mit die in­newohnende Komplexität be­herrschbar zu machen. Zudem soll eine gemein­same Kommuni­kationsbasis zwischen Auftraggeber und Entwicklern ge­schaffen werden. Dadurch können sowohl Fehler als auch ganze Fehlentwicklungen vermie­den und Schwachstellen aufgedeckt werden [ÖSTE97, S. 388].

2 Vorgehensweise und Konzepte zur Modellerstel­lung

Die Beschrei­bung der SA setzt die Kenntnis der o. g. Basiskonzepte, des Top-down-Ansatzes sowie des Entity-Relationship-Modells (ERM) voraus. Im Folgenden wer­den die wesentlichen Vorgehensweisen und Ideen dieser Grundlagen zusammenge­fasst. An­wendungsbeispiele werden entweder sofort explizit genannt oder später bei der Dar­stellung der SA aufgezeigt (vgl. Kapitel 3).

2.1 Top-down-Methode

Ein übersichtlicher, vollständiger und widerspruchsfreier Entwurf kann nur dann ent­stehen, wenn bei der Erstellung nach einem festen Prinzip vorgegangen wird. Bei der Top-down-Methode wird eine Gesamtaufgabe schrittweise in mehrere logisch zu­sammenhängende Teilaufgaben zerlegt (Spezialisierung). Der Abstraktionsgrad wird dabei mit jeder hinzugefügten Hierarchieebene reduziert. Iterativ wird eine Verfei­ne­rung so lange vorgenommen bis kleine überschaubare Einheiten (Module) entste­hen. Eine solche Vorgehensweise erhöht die Übersichtlichkeit und Wartungsfreund­lich­keit komplexer Systeme und ermöglicht eine klare Definition von Schnittstellen [STAH99, S. 276 und THOM90, K 3.1, S. 1f.].

2.2 Datenflussdiagramm

Ein Datenflussdiagramm visualisiert den Weg von Daten, die aus der Umge­bung in das System hineinfließen (Quelle), durch Prozesse umgewandelt, in Spei­chern tem-po­rär abgelegt oder aus diesen gelesen werden und in die Umgebung zu­rückflie­ßen (Senke) [BALZ01, S. 145]. Es ist darauf zu achten, dass alle Ele­mente eindeu­tige und aussa­ge­kräftige Namen besitzen. Die vier wich­tigsten Symbole und ihre Be­deu­tung sind in Abbildung 1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Symbole des Datenflussdiagramms [BALZ01, S. 142]

Einen Datenfluss kann man sich als Kanal vorstellen, durch welchen ein Paket von Informationen, d. h. zusammengehörende Daten, geschickt werden. Die Richtung wird dabei durch Pfeile angezeigt. Das Paket ‚Adresse’ besteht bspw. aus den Kom­po­nen­ten Straße, Postleitzahl und Ort. Kann für einen Datenfluss kein geeigneter Name ge­funden werden, so ist es wahrscheinlich, dass diese Daten derart unter­schiedliche In­formationen tragen, dass sie durch verschiedene Datenflüsse repräsen­tiert werden sollten.

In Datenflussdiagrammen werden Zusammenhänge zwischen Prozessen oder auch Beziehungen dieser zu Speichern oder Schnittstellen dargestellt. Ein Prozess wird dabei verstanden als Abarbeitung von Anweisungen, wobei eingehende in ausgehen­de Daten transformiert werden. Ein Beispiel hierfür ist die Berechnung des Gehalts als Ausgangsdatum, welches aus den Eingangsdaten wie z. B. Arbeitszeit, Stunden­lohn usw. ermittelt wird. Der Speicher stellt einen Aufbewahrungs­ort von Infor­mati­onen dar. Er muss dementsprechend nicht nur ein Speicher im Sinne einer Da­ten­bank, son­dern kann vielmehr auch ein Buch oder sogar ein Papierkorb sein. Schnitt­stellen zur Umwelt sind Personen oder Organisationen, welche außerhalb des Kon­textes des zu modellie­renden Systems liegen [DEMA78, S. 52-59].

Ein An­wendungsbeispiel für das Zusammenspiel dieser Komponenten folgt im Ver­lauf dieser Arbeit.

2.3 Data Dictionary

Ein Data Dictionary ist ein organisiertes Verzeichnis aller Daten, die von ei­nem Sys­tem verwaltet und ausgetauscht werden [THOM90, D 4.5, S. 1]. Es enthält Informa­tionen bzgl. Struktur, Eigen­schaften und Verwendung. Definiert werden die Daten­flüsse und ihre Komponenten, die verwendeten Speicher, alle weiteren Elemente, die einer näheren Beschreibung bedürfen sowie zusätzliche Informationen wie bspw. Prioritäten oder Volumina [DEMA78, S. 126].

Tabelle 1: Symbole des Data Dictionary (in Anlehnung an [SCHÖ90, S. 70])

Abbildung in dieser Leseprobe nicht enthalten

Der Vorteil eines Data Dictionarys besteht darin, dass Inkonsistenzen so­wie Re­dun­danzen und die damit einhergehende Fehleranfälligkeit verringert wer­den [BALZ01, S. 247]. Die Zusammensetzung der Daten aus Komponenten basiert auf den in Ta­belle 1 aufgezeigten Notationen, wobei nur die wichtigsten aufgezeigt sind. In Kapi­tel 3.1.3 wird die Verwendung der Symbole anhand eines Beispiels aufgezeigt.

2.4 Pseudo-Code

Der Pseudo-Code ist eine semiformale Beschreibung der Logik von Pro­grammmo­dulen. Er dient dazu, den Ablauf eines Algorithmus darzustellen und ermöglicht da­durch eine Übersicht, aus der ersichtlich ist, ob und wie oft Anweisungen ausge­führt werden sollen. Für die Kontrollstrukturen werden Schlüsselwörter der Pro­grammier­sprachen wie if, else, while, for, do usw. verwendet. Die Anweisungen selbst sind hingegen verbale Be­schreibun­gen. Weiterhin sind Komponenten, welche im Data Dictionary definiert sind, enthalten.

Tabelle 2: Kontrollstrukturen [BALZ01, S. 261-264])

Abbildung in dieser Leseprobe nicht enthalten

Eine so erstellte Kurzfassung des Programms erleichtert die end­gültige Kodierung wesentlich und dient als Kommunikationsbasis für alle Beteilig­ten. Allerdings bedarf es eines hohen Aufwands, um alle Funkti­onen des Systems korrekt zu beschreiben.

Beispiele der wichtigsten Kontroll­struktu­ren sind in Tabelle 2 dargestellt. Eine Se­quenz beschreibt die Ausführung mehrerer Anwei­sungen hin­tereinander. Bei einer Auswahl erfolgen Anweisungen in Abhän­gigkeit bestimmter Bedingungen. Das Konzept der Wiederholung wird angewendet, wenn Anweisungen in Abhängigkeit von einer Bedingung oder für eine bestimmte Anzahl mehrfach aus­geführt werden sollen [SCHÖ90, S. 214-217]. Eine strukturierte Darstellung des Pseudo-Codes wird durch das Einrücken von Unterabläufen erreicht [SILV89, S. 83]. DeMarco be­zeichnet diese Art der Darstellung auch als „Structured English“ [DEMA78, S. 180]. Eine konkrete Anwendung wird in Kapitel 3.1.4 aufgezeigt.

2.5 Entscheidungstabellen und Entscheidungsbäume

Entscheidungstabellen dienen der Darstellung der Entscheidungslogik von Pro­zes­sen. In tabellarischer Form werden Aktionen, die von der Erfüllung oder Nichter­fül­lung von einer oder mehrerer Bedingungen abhängen, kompakt und übersichtlich strukturiert. Eine Entscheidungstabelle besteht aus den in Tabelle 3 dargestellten vier Quad­ranten.

[...]