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.
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.
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 Umgebungsmodell 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 Informationen 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 Darstellung wird der Prozessname abgebildet und zusätzliche Eigenschaften wie Terminatoren (Menschen, Organisationen, Systeme), Austauschdaten mit dem externen Umfeld, Datenspeicher 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 Einfluss 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 darstellt, 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 Kontextdiagramm 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 eigener Prozess in der nächst höheren Ebene entsteht. Die Prozesse werden nun so oft verdichtet, 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 Vollständigkeit mit dem DFD-Modell überprüft, woraufhin die einzelnen Prozesse in „strukturierte Sprache“, auch Prozessspezifikation genannt, umgewandelt werden. In Abbildung 5 ist diese Prozessspezifikation 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 Zielsetzung und die Konkretisierung des Ziels deutlich werden.
3.2.1.2 Das Aktivitätsdiagramm
Zur Darstellung des Zusammenhangs zwischen System und Umgebung werden Informationen 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 Fachexperten, die qualifiziert fachliche Fragen beantworten können, nach Anforderungsverantwortlichen, 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, welches 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 Ausprägungen, wie Name, Kurzbeschreibung, Akteure und Ergebnissen, und funktionalen Anforderungen, wie Verbindlichkeitsgrad und Priorität, unterschieden wird.
3.2.1.4 Das fachliche Glossar
Das fachliche Glossar enthält alle Definitionen aller wichtigen fachlichen Begriffe, Gegenstä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
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.