Strukturierte und objektorientierte Analyse

Inhalt

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Strukturierte Analyse

2.1 Einführung
2.2 Der Prozessablauf
2.2.1 Die Umgebung
2.2.1.1 Die Zweckspezifikation
2.2.1.2 Das Kontextdiagramm
2.2.1.3 Die Ereignistabelle
2.2.1.4 Das Datenverzeichnis
2.2.2 Das Modell

3 Objektorientierte Analyse
3.1 Einführung
3.2 Der Prozessablauf
3.2.1 Die Umgebung
3.2.1.1 Die Zweckspezifikation
3.2.1.2 Das Aktivitätsdiagramm
3.2.1.3 Die Ereignisse
3.2.1.4 Das fachliche Glossar
3.2.2 Das Modell

4 Gegenüberstellung
4.1 Gemeinsamkeiten
4.1.1 Problembereiche
4.1.2 Stärken
4.1.3 Schwächen
4.2 Unterschiede
4.2.1 Ablauf
4.2.2 Vorteile
4.2.3 Nachteile
4.2.4 Kosten

5 Schlussbetrachtung

Quellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Systementwicklung

Abbildung 2: Grenze zwischen System und Umgebung

Abbildung 3: Kontextdiagramm

Abbildung 4: Rohentwurf mit Datenspeicher

Abbildung 5: Prozessspezifikation: Beispiel Flugauskunft

Abbildung 6: Aktivitätsdiagramm

Abbildung 7: Objektflussdiagramm

Abbildung 8: Schnittstellen

Tabellenverzeichnis

Tabelle 1: Projekt-Ansprechpartner

Tabelle 2: Ablaufunterschiede

1 Einleitung

Die Entwicklung von Software ist sehr aufwändig und umfangreich. Um den Prozess der Softwareentwicklung einfacher zu gestalten, unterteilt man ihn in drei Schritte: Zuerst wird das zu lösende Problem, für welches eine neue Software hergestellt werden soll, definiert, was bedeutet, dass die Realität in einem abstrakten Modell dargestellt wird. Dies geschieht in der Analysephase, dem ersten Schritt der Softwareentwicklung.

Im zweiten Schritt, der Designphase, wird eine Lösung zu dem Problem aus Schritt 1 dargestellt und im dritten Schritt, der Implementierung, erfolgt die Programmierung der erstellten Lösung aus Schritt 2.

Wie in Abbildung 1 zu erkennen ist, sind diese einzelnen Phasen aufeinander aufgebaut.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung : Systementwicklung

Diese Arbeit konzentriert sich auf die Phase der Analyse, welche durch zwei verschiedene Vorgehensweisen beschrieben werden kann: die strukturierte und die objektorientierte Analyse.

In den siebziger Jahren wurde von Tom DeMarco erstmalig die strukturierte Analyse beschrieben. Sie bedient sich der Top-Down-Methode, welche in Punkt 2 näher erläutert wird. In den neunziger Jahren entstand die objektorientierte Analysemethode, welche nach dem Bottom-Up-Ansatz analysiert. Auch dieser wird in den folgenden Ausführungen, in Punkt 3, näher erörtert.

Im weiteren Verlauf werden außerdem beide Methoden gegenübergestellt, um die Stärken und Schwächen, die Kosten, die Vor- und Nachteile, den Ablauf insgesamt und die Effizienz zu beurteilen.

2 Strukturierte Analyse

2.1 Einführung

Die strukturierte Analyse (SA) ist eine Methode der Systemanalyse. Sie wurde in den siebziger Jahren von Tom DeMarco eingeführt und beschrieben als „[...] the study of a problem, prior to taking some action. In the specific domain of computer systems development, analysis refers to the study of some business area or application, usually leading to the specification of a new system.”^[1] Im nächsten Punkt wird der Ablauf der SA erläutert.

2.2 Der Prozessablauf

Zur Modellerstellung anhand der strukturierten Analyse sind zwei Hauptkomponenten notwendig: das Umge­bungs­modell und das Verhaltensmodell^[2], welche im weiteren Verlauf näher erläutert werden.

2.2.1 Die Umgebung

In diesem Abschnitt werden die Schnittstellen zwischen System und Umgebung aufgezeigt. Um dies in einem Umgebungsmodell darstellen zu können, muss untersucht werden, welche Infor­mationen aus dem externen Umfeld in das System hineingehen, welche Informationen das System produziert und welche an das externe Umfeld abgegeben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Grenze zwischen System und Umgebung^[3]

Zur Definition des Umfeldes sind vier Komponenten notwendig:

- die Zweckspezifikation,
- das Kontextdiagramm,
- die Ereignistabelle und
- das Datenverzeichnis.

2.2.1.1 Die Zweckspezifikation

Bei der Zweckspezifikation wird der Zweck des Systems definiert, welcher hauptsächlich für nicht Involvierte (die Firmenleitung, Abteilungsleiter oder andere Auftraggeber) relevant ist, da diese nicht direkt in den Prozess eingebunden sind und durch diese Zielerfassung die Kosten und den Nutzen des geplanten Systems erfassen können.

2.2.1.2 Das Kontextdiagramm

Das Kontextdiagramm ist eine Sonderform des Datenflussdiagramms. In der Mitte der Dar­stellung wird der Prozessname abgebildet und zusätzliche Eigenschaften wie Terminatoren (Men­schen, Organisationen, Systeme), Austauschdaten mit dem externen Umfeld, Daten­speicher und die Grenze zwischen dem System und dem Rest der Welt. Die Daten werden durch Flüsse dargestellt. In folgendem Beispiel ist der Prozess ein Online-Kauf, auf den der Kunde als Terminator und das Finanzamt durch die Mehrwertsteuer als externes Umfeld Ein­fluss hat.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Kontextdiagramm

2.2.1.3 Die Ereignistabelle

Die Ereignistabelle ist eine textliche Liste, in der alle Ereignisse dargestellt sind, die im Umfeld auftreten und worauf das System reagieren muss. Ein Beispiel ist die Internet-Bestellung eines Kunden bei einem Versandhaus.

2.2.1.4 Das Datenverzeichnis

Im Datenverzeichnis werden alle Beschreibungen und auch die Bedeutung der verwendeten Daten aufgelistet. Es wird bis zur Fertigstellung des Datenmodells weiter geführt.

2.2.2 Das Modell

Das Modell wird bei der SA als Verhaltensmodell beschrieben, da es das interne Verhalten dar­stellt, welches das System zeigen muss, um in der Umgebung erfolgreich zu bestehen. Zur Modellerstellung sind drei Schritte notwendig:

- die Erstellung eines Rohentwurfs,
- die Fertigstellung des DFD und
- die Prozessspezifikation.

Im vorläufigen Modell, einem Datenflussdiagramm, wird jedes Ereignis der Ereignistabelle als Prozess dargestellt mit der Antwort, die das System auf dieses Ereignis geben soll. Anschlie­ßend werden die Eingaben dieses Rohentwurfs mit den Eingaben im Kon­text­dia­gramm abgeglichen. Die Prozesse kommunizieren über Datenspeicher, welcher in Abbildung 4 durch den Namen „Aufträge“ dargestellt ist. Geht ein Kundenauftrag ein, wird dieser bearbeitet, die Daten werden gespeichert und die Anfrage wird erwidert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Rohentwurf mit Datenspeicher^[4]

Für die Fertigstellung des Datenflussmodells wird der Rohentwurf verdichtet, was bedeutet, dass eng verwandte Prozesse zu Gruppen zusammengestellt werden, woraus wiederum ein eige­ner Prozess in der nächst höheren Ebene entsteht. Die Prozesse werden nun so oft ver­dich­tet, bis nur noch wenige in oberster Ebene übrig sind und das Modell an Übersichtlichkeit zunimmt.

Im Folgenden wird das bislang geführte Datenverzeichnis auf Stimmigkeit und Voll­stän­dig­keit mit dem DFD-Modell überprüft, woraufhin die einzelnen Prozesse in „strukturierte Spra­che“, auch Prozessspezifikation genannt, umgewandelt werden. In Abbildung 5 ist diese Pro­zess­spe­zifikation am Beispiel einer Online-Flugauskunft dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Prozessspezifikation: Beispiel Flugauskunft^[5]

Parallel zur Erstellung des DFD wird häufig ein Entity-Relationship-Diagramm (ERD) erstellt. Dies ist ein Netzmodell, welches die Beziehungen zwischen Objekten darstellt. Auch das ERD wird zuerst als Rohversion erstellt, überarbeitet und schließlich verbessert.

Beide Diagramme können somit aufeinander abgestimmt werden.

Die Analysephase ist mit der Erstellung dieser Modelle abgeschlossen.

3 Objektorientierte Analyse

3.1 Einführung

Auch die objektorientierte Analyse (OOA) ist eine Methode der Systemanalyse. Sie wurde in den neunziger Jahren entwickelt und durch Rumbaugh beschrieben: „The purpose of object-oriented analysis is to model he real-world system so that it can be understood. The successful analysis model states what must be done, without restricting how it is done, and avoids implementation decisions.”^[6]

Viele Einzelschritte der OOA werden parallel durchgeführt. Zum besseren Vergleich mit der SA werden die einzelnen Aktivitäten im Folgenden wie in Punkt 2 dargestellt.

3.2 Der Prozessablauf

Zur Durchführung der Analyse anhand der OOA wird zu Beginn die Umgebung des Systems untersucht und anschließend das abstrakte Modell erstellt.

3.2.1 Die Umgebung

Die Analyse der Schnittstellen zwischen System und Umgebung der OOA setzt sich aus vier Punkten zusammen: der Zweckspezifikation, dem Aktivitätsdiagramm, den Ereignissen und dem fachlichen Glossar. Diese Komponenten werden im weiteren Verlauf näher erläutert.

3.2.1.1 Die Zweckspezifikation

Zu Beginn der OOA wird die Systemidee schriftlich formuliert, wodurch die grundsätzliche Ziel­setzung und die Konkretisierung des Ziels deutlich werden.

3.2.1.2 Das Aktivitätsdiagramm

Zur Darstellung des Zusammenhangs zwischen System und Umgebung werden Infor­matio­nen gesammelt, welche

- die Anforderungsbeitragenden,
- die Geschäftsprozesse, die das System unterstützen soll,
- die einzelnen Geschäftsanwendungsfälle und
- die Projekt-Ansprechpartner identifizieren.

Die Projekt-Ansprechpartner unterscheiden sich, wie in Tabelle 1 aufgelistet, nach Fach­exper­ten, die qualifiziert fachliche Fragen beantworten können, nach Anfor­derungs­ver­ant­wort­lichen, die die Anforderungen an das System festlegen, und nach Systembetroffenen, die vom System direkt betroffen sind.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Projekt-Ansprechpartner^[7]

Die Ablauforganisation eines Unternehmens wird schließlich in einem Aktivitätsdiagramm, wel­ches eine Möglichkeit zur Illustration ist, dargestellt. Abbildung 6 zeigt ein Beispiel für eine Kfz-Reservierung via Internet: Sollte eine Reservierung möglich sein, wird das Kfz reserviert, übergeben, vom Mieter benutzt, zurückgegeben, abgerechnet und schließlich vom Vermieter wieder mietbereit gemacht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Aktivitätsdiagramm^[8]

3.2.1.3 Die Ereignisse

Die Ereignisse werden in einer textlichen Liste festgehalten, in der nach konkreten Aus­prä­gun­gen, wie Name, Kurzbeschreibung, Akteure und Ergebnissen, und funktionalen An­for­derun­gen, wie Ver­bind­lich­keits­grad und Priorität, unterschieden wird.

3.2.1.4 Das fachliche Glossar

Das fachliche Glossar enthält alle Definitionen aller wichtigen fachlichen Begriffe, Gegen­stände, Konzepte, Zustände und Prozesswörter.

3.2.2 Das Modell

Die Erstellung eines Modells setzt sich bei der OOA aus drei Teilbereichen zusammen:

- dem Anwendungsfall-Ablaufmodell,
- den Schnittstellen und
- dem Prototyp.

[...]

---

^[1] Quelle: DeMarco (1979), S. 4

^[2] Quelle: Yourdon (1992), S. 391ff.

^[3] Quelle: Yourdon (1992), S. 392

^[4] Quelle: Yourdon (1992), S. 428

^[5] Quelle: Raasch (1993), S. 94

^[6] Quelle: Rumbaugh (1991), S. 148

^[7] Quelle: Oestereich (2001), S. 90

^[8] Quelle: Oestereich (2001), S. 93