Information Technology Reference
In-Depth Information
Vorgehensmodell aus Ansätzen beider Modellklassen bedient (best practices), erscheint es
sinnvoll, sich diese klassischen Vorbilder zunächst zu verdeutlichen.
Klassische Vorgehensmodelle haben ihren Ausgangspunkt in der strukturierten Pro-
grammierung , d. h., man bedient sich hierbei des Unterprogrammkonzepts und des Kon-
zepts von Kontrollstrukturen. Entsprechende Modelle wurden bereits in den 70er Jahren
des zwanzigsten Jahrhunderts entwickelt. Da es bei der strukturierten Programmierung
im Gegensatz zur objektorientierten Programmierung keine Integration von Daten und
zugehörigen Funktionen gibt, werden in den klassischen Vorgehensmodellen Daten und
Abläufe getrennt voneinander modelliert. So werden heim Systementwurf die Daten bei-
spielsweise durch Entity-Relationship-Modelle und die Systemfunktionen und Informa-
tionsflüsse durch Datenflussdiagramme dargestellt (Chen 1976 ).
Bereits bei den klassischen Modellen spielt die Top-Down-Vorgehensweise eine wichti-
ge Rolle, also das schrittweise Vorgehen vom Allgemeinen/Abstrakten zum Detaillierten/
Konkreten. Dabei wird zumeist erst ein grobes Systemmodell erstellt, auf dieser Basis
dann ein konkreter, detaillierter Entwurf erarbeitet und eventuell in einem Prototyp früh-
zeitig erprobt, um dann diesen Prototyp schließlich in ein lauffähiges Programm umzu-
setzen. In den einzelnen Stufen werden verschiedene Beschreibungsformen benutzt, bei-
spielsweise Entity-Relationship- und Datenflussdiagramme in den abstrakteren Modellen,
sowie Relationen und Struktogramme oder Programmablaufpläne in den implementa-
tionsnäheren Modellen. Problematisch sind hier jeweils die semantischen und visuellen
Brüche zwischen den Beschreibungsformen der unterschiedlichen Phasen und auch inner-
halb der einzelnen Phasen, die ja getrennte Daten- und Funktionsmodelle enthalten. Die-
se Brüche machen jeweils eine explizite Umformung bzw. Anpassung der Darstellungen
erforderlich.
Objektorientierte Vorgehensmodelle kamen mit dem zunehmenden Erfolg objektorien-
tierter Programmiersprachen auf (Kilberth et al. 1993 ). Sie übertragen deren Prinzipien
von der eigentlichen Programmierung auf den Entwurf von Systemen. Das Ziel dieser
modernen Modelle ist die Entwicklung von Systemen, die aus einer Menge kooperie-
render Hard- und Softwareobjekte bestehen. Die Objekte werden dabei meist nicht zu
vordefinierten Abläufen zusammengesteckt, wie es bei algorithmenorientierten Syste-
men mit Unterprogrammen der Fall ist. Vielmehr werden sie als Anbieter und Nutzer von
Diensten verstanden, die in einer nicht vorherbestimmten zeitlichen Abfolge zusammen-
arbeiten. Dieses Prinzip findet sich zum Beispiel bei der ereignisgesteuerten Programmie-
rung sowie beim Client-Server-Ansatz, der auch bei der Realisierung verteilter Systeme
eine zentrale Rolle spielt. Der Vorteil der objektorientierten Modellierung liegt in ihrer
methodischen Geschlossenheit , da Objekte in allen Phasen des Entwicklungsprozesses
als grundlegendes Modellierungsmittel eingesetzt werden. Hierdurch werden die beiden
Nachteile der klassischen Ansätze überwunden: Daten und Funktionen werden in Objek-
ten integriert, so dass es für sie keine zwei getrennten Modelle mehr gibt. Auch zwischen
den Phasen treten keine Brüche bezüglich der Darstellungsform mehr auf. Als Notations-
sprache für alle Phasen eines objektorientierten Entwicklungsprozesses kann man sich der
Unified Modeling Language (UML) bedienen.
Search WWH ::




Custom Search