Probleme traditioneller Softwaresysteme

Das Paradebeispiel eines erfolgreichen, traditionellen Softwaresystems ist SAP, unzweifelhaft das bezüglich seiner Funktionalität und seines Leistungsumfangs mächtigste integrierte Softwarepaket. Bekannt sind aber auch die Probleme

 

Beim Grobentwurf einer Software-Systemarchitektur steht man vor der Frage, ob die Struktur eher auf den gewünschten Aktionen oder auf den Daten, Informationen und zu manipulierenden Objekten aufsetzen soll. Sowohl Aktionen als auch Daten sind wichtig für das Programmsystem. Man muß sich entscheiden, wovon man ausgehen will. Im Werdegang eines Systems sind Funktionen der eher flüchtige Teil. Neue Anforderungen entstehen stetig aus den anfänglichen. Wenn die Architektur zu sehr auf den Funktionen beruht, dann ist nicht gewährleistet, daß die Weiterentwicklung des Systems ebenso gleitend erfolgen kann, wie die Weiterentwicklung der Anforderungen fortschreitet. Wenn ein System sich entwickelt, können seine Aufgaben sich radikal ändern. Sehr viel mehr Beständigkeit dagegen findet sich in den Datenarten, auf denen gearbeitet wird.

Fast alle heute verfügbaren integrierten Softwaresysteme verwenden die top-down-funktionale Methode. Diese Methode beruht auf der Idee, die gesamte Software aus der schrittweisen Verfeinerung der abstrakten Hauptfunktion des Systems zu gewinnen. Der Top-down-Ansatz ist eine logische, organisierte Denkdisziplin, die eine geordnete Systementwicklung fördert und die Komplexität des Aufgabenfeldes stufenweise reduziert. Leider fördert diese Methode noch nicht die Wiederverwendbarkeit der Software.

Die größten Probleme in Bezug auf die Top-down-Methode hat man mit der Stetigkeitsanforderung an die Software, d.h. an das kontinuierliche Weiterentwickeln-Können bei sich verändernden Anforderungen. Funktionen sind der sich am schnellsten ändernde Teil eines Systems; die funktionale Zerlegung wird aber bei der Top-down-Methode als Hauptkriterium der Strukturierung benutzt. Die kurzfristige Bequemlichkeit einer recht einfach gewonnenen Anfangsstruktur wird durch eine langfristige Katastrophe erkauft: wenn das System sich ändert, stehen die Entwickler vor der Aussicht auf einen ständigen Neuentwurf.

Gegen diese Softwarearchitektur steht der objektorientierte Entwurf. Darunter ist diejenige Methode zu verstehen, die zu Softwarearchitekturen führt, die auf den von einem System oder Teilsystem bearbeiteten Objekten beruhen und nicht auf den Funktionen, die das System realisieren soll. Das Plädoyer für die Benutzung der Daten(objekte) als Schlüssel zur Systemmodularisierung wird v.a. auf die Qualitätsziele Verträglichkeit, Wiederverwendbarkeit und Erweiterbarkeit gegründet. Man fragt also nicht, was das System tut, sondern woran es etwas tut.