Ziel der angewandten Methoden einer Software Entwicklung ist immer die kostengünstige Erzeugung hochwertiger Software. Um diese von anderer Software abzugrenzen werden im Weiteren, ohne Anspruch auf Vollständigkeit, folgende SW-Qualitäten unterschieden: Korrektheit, Zuverläßlichkeit und Benutzerfreundlichkeit auf der Anwenderseite sowie Wiederverwendbarkeit und Portierbarkeit auf Seiten des Herstellers. Hat sich im Lauf der Zeit die genutzte Methode geändert, so geschah dies aufgrund veränderter Umgebungsparameter - wie höhere Problemkomplexität - die ein Erreichen der erforderlichen Softwarequalität zu teuer machten und so eine neue Methodik erzwangen.
In den Anfängen der Informatik wurden Probleme "direkt" gelöst. Entwickler, Codierer und Anwender waren in einer Person vereint, die bei geringer Programmkomplexität keine Schwierigkeiten hatte, das Problem mit ad-hoc Methoden und hardwarenahen Programmiersprachen, wie Binärcodierung oder Assembler, in einer Umgebung, in der Hardware weit teurer als Software war, lösungbildend umzusetzen.
Als klassische Software-Entwicklungsmethode wurde die "Strukturierte Analyse" genutzt. Bei dieser werden Daten- und Verhaltensaspekte eines Programmes für jede Phase (Analyse, Entwurf, Implementierung) dieses Verfahrens getrennt betrachtet und mit eigenen Diagrammen dargestellt. Fehler im Code wurden dabei mittels "try and error" solange debuggt, bis die gewünschte Zuverläßlichkeit und Korrektheit erreicht wurde. Benutzerfreundlichkeit wurde dabei (notwendigerweise) als vernachlässigbar betrachtet, der Nutzer hatte sich dem Programm anzupassen, wenn er den Computer sinnvoll einsetzen wollte.
Nach und nach veränderte sich obige Komplexität-, Kosten- und Entwicklungsstruktur. Mit Zunahme der Problemkomplexität stieg die Fehleranzahl in den Programmen. Daraus folgte eine vermehrte debugging-Tätigkeit, die den Programmcode noch unübersichtlicher und unverständlicher machten. Späteres Bearbeiten des Codes wurde so durch die verschiedensten nicht dokumentierten Zugriffe und Methoden nahezu unmöglich und die Kosten der Softwareentwicklung stiegen überproportional während die erreichten Softwarequalitäten, vor allem in Hinsicht auf Wiederverwendbarkeit, Zuverlässigkeit und Bedienerfreundlichkeit, stetig abnahmen.
Eine Fernwirkung, das Y2K Problem, erleben wir derzeit. Die eigentliche Problematik ist dabei nicht das 2stellige Abspeichern der Jahreszahl, den dieses wäre leicht lösbar, sondern die vielen, im Programm versteckten, nicht dokumentierten Zugriffe auf diese Speicherung, die eine 2stellige Zahl erwarten und bei denen eine 4stellige Zahl z.B. einen Speicherüberlauf, einen Indexfehler, eine Division durch Null oder einfach nur einen schweren Ausnahmefehler bewirken.
Ein weiteres Problem ergab sich durch die verwendeten Programmiersprachen und deren Konzepte, allen voran der prozedurale Ansatz, die oft ein Umdenken vom Codierer erforderten, da Funktionalität und Datenstruktur einer starken Trennung unterworfen wurden.So kam es `68 zu der sogenannten Softwarekrise und in Folge davon zur NATO-Konferenz in Garmisch-Partenkirchen, bei der Lösungsmöglichkeiten dieser Probleme formuliert wurden:
Um die Problemkomplexität zu senken muß das Programm, bereits während der Entwurfphase, in, für den Codierer überschaubare Teile, modularisiert wird.
Die linearen Methoden wurden aufgrund ihrer Nachteile, Auftraggeber/Anwender sind an der Entwicklung nur wenig beteiligt, unrealistische strikte Reihenfolge, viele Anforderungen an das Programm stehen zu Beginn gar nicht fest, durch Methoden ersetzt, die einen Rückgriff während der Entwicklung erlauben.
Die bisher verwendeten Programmiersprachen, deren fehlertolerante Compiler nur geringe, bzw. gar keine Datenprüfungen sowie statische oder dynamische array index checks vornehmen, wurden durch restrektivere Sprachen/Compiler ersetzt.
Das Schlagwort der heutigen Software Entwicklung ist Objektorientierung. Im Vergleich zu klassischen Methoden erfordert dieses Konzept einen Mehraufwand von ca. 20%, trotzdem gibt es derzeit fast kein größeres Projekt, daß ohne objektorientierte Vorgehensweise abgeschlossen werden kann.
Ein großer Vorteil des objektorientierten Ansatzes besteht darin, daß die Modellierung des Programms eher dem intuitiven Verständnis des Problembereiches entspricht, da Funktionen und Daten nicht mehr getrennt betrachtet, sondern für jede Phase (Analyse, Entwurf, Implementierung) gekapselt, werden.
Weitere Vorteile der Objektorientierung werden durch die Betrachtung ihrer Kernkonzepte deutlich:
Objekt: Zentraler Begriff der Objektorientierung. Dieses ist durch Zustand (Attribute), Verhalten (Methoden) und Identität (Bezeichnung) gekennzeichnet. Durch die Möglichkeit, Gegenstände der Realität als Objekte abbilden zu können, wird z.B. aus dem Gegenstand Stuhl das Objekt Stuhl mit seinen Zuständen, wie Gewicht, Größe, Farbe, Ausrichtung, seinem Verhalten, wie auf Knopfdruck, kippt er nach vorne und seiner Identität, Stuhl XYZ. Objekte werden im Programm als in sich geschlossene (gekapselte) Einheit behandelt.
Klasse: In einer Klasse werden ähnliche Objekte zusammengefaßt. Sie dient somit zur Beschreibung von Objekten mit nahezu gleichem Verhalten. Alle Objekte einer Klasse werden als Instanzen beschrieben. So ist unser Stuhl XYZ eine Instanz der Klasse Schreibtischstühle.
Vererbung: Bei der Vererbung werden alle Methoden und Attribute einer Oberklasse an eine Unterklasse weitergegeben. So hat die Klasse Schreibtischstühle z.B. eine Oberklasse Stühle, von der sie die Existenz einer Lehne erbt. Dank dieser Eigenschaft ist es möglich, abstrakte Oberklassen zu schreiben, die auch in anderen Programmen Verwendung finden können.
Kapselung: Die Attribute und Methoden eines Objektes werden über Schnittstellen angesprochen. Dadurch ist es völlig unerheblich, wie diese intern realisiert wurden. Aufgrund dieser Schnittstellen ist eine nachträgliche änderung der internen Darstellung problemlos möglich, da von außen nur auf die Schnittstellen zugegriffen wird. Bisher mußte immer das gesamte Programm bei änderungen durchforstet werden, wäre z.B. unter der Beachtung der Y2K-Problematik alles objektorientiert programmiert worden, müßte man nur die interne Darstellung für alle Module von 2 auf 4 Stellen erweitern.
Diese Konzepte bewirken durch ihren Aufbau, auch bei komplexeren Problemen einen übersichtlichen, modularen Quellcode, der qualitativ hochwertig und somit, wie aufgeführt, wiederverwendbar, portierbar, zuverlässig, korrekt und benutzerfreundlich ist.
Ergänzend wurden die herkömmlichen, prozeduralen Sprachen, soweit möglich, durch neuere Sprachen wie C++ oder Java. Diese unterstützen bereits aufgrund ihres Aufbaus die objektorientierte Programmierung und verfügen über fehlerintolerante Compiler. Als weiterer Trend zeichnet sich hier die Programmierung in Entwicklungsumgebungen, wie Visual Basic, Visual C++, Delphi, Powerbuilder ab. Vorteil dieses Vorgehensweisen ist, daß die eigentliche Programmierung in den Hintergrund rückt und durch ein ganzheitliches Applikationsdesign abgelöst wird. Dabei werden Masken und Fenster zuerst entworfen; über die Objekte wird die Applikationslogik gesteuert.
Unterstützend greift man während der Entwicklung auf interaktive Modelle, wie evolutionäre Software Entwicklung oder Spiralmodell nach Boehm, die ein Backtracking erlauben, zurück.
Heutige Ziele der Software Entwicklung fordern einen möglichst flexiblen Entwurf und eine effiziente, sichere und portablen Implementierung. Ergänzt werden heutige Methoden um homogene Diagrammkonzepte wie UML oder softwaregesteuerte Entwicklung wie CASE.
Modellierung ist der zentrale Bestandteil aller Aktivitäten, für die Entwicklung guter Software. UML unterstützt die einheitliche Modellierung durch seinen Aufbau. Die Phasen Analyse und Entwurf werden mit Hilfe verschiedener aufeinander abgestimmter Diagramme und deren definierten Schnittstellen zusammengefaß. Eine Implementierung kann nach der Modellierung mit Hilfe von geeigneten Programmen, wie z.B. Rational Rose, Innovator 6.0 oder Together / J 1.0 automatisch geschehen.
Die wichtigsten in UML verwendeten Diagramm sind:
Use Case Diagramm folgend direkt aus der Problemanalyse. Die wichtigsten Systemoperationen werden als "use case" abgebildet, womit eine statische Ansicht des Sytems entsteht.
Strukturdiagramme erstellen Objektmodelle, die Datenaspekte und somit die Frage nach dem Wer, betrachten. Zu den Strukturdiagramm gehört das Klassendiagramm.
Klassendiagramme sind bezüglich der Modellierung von objektorientierten Systemen die verbreitetsten Diagramme. Ein Klassendiagramm verdeutlicht mehrere Klassen, ihre Methoden und Verknüpfungen und zeigen das statische Design eines Systems. Die Use Case werden zu Klassen, mit den beschriebenen Operationen der Aufgabenstellung als Methoden. Notwendige weitere Klassen werden aus der Aufgabenstellung heraus ergänzt.
Verhaltensdiagramme betrachten den dynamischen (wann) bzw. funktionalen (was) Verhaltensaspekt eines Modelles. Zu den Verhaltensdiagrammen gehören Interaktions-, Zustands-, Aktivitäten- und Sequenzdiagramme.
Interaktionsdiagramme zeigen Objekte, ihre Abhängigkeiten und Interaktionen einschließlich der Kommunikation. Das Kollaborationsdiagramm ist ein Interaktionsdiagramm.
Kollaborationsdiagramme sind objektorientiert und heben die strukturale Organisation der Objekte und ihrer Beziehungen hervor. Inhaltlich hängen sie stark mit dem Sequenzdiagramm zusammen und ergeben sich aus den Klassendiagrammen.
Zustandsdiagramme beschreiben als dynamisches Modell sequentielle Abläufe. Um Nebenläufigkeit zu modellieren werden Statecharts benutzt. Zustandsdiagramme wie Statechart ergeben sich aus einer Klasse des Klassendiagrammes, ihrer Methoden welche die Zustandsübergänge darstellt und sind semantisch nahezu. Sie beschreiben erlaubte Zustandsfolgen eines Objektes bzw. erlaubte Aufrufreihenfolgen für die Operationen auf einem Objekt
Aktivitätendiagramme sind eine besondere Art der Statechart Diagramme, die den Datenfluß von einer Aktivität zur nächsten innerhalb eines Systemes zeigen. Sie beschreiben so eine dynamische Sytemansicht und sind wichtig, um die Funktionen eines Sytemes zu modellieren. Eingesetzt werden sie zur Beschreibung komplexer Operationen, insbesondere zur Verfeinerung des Use Case Diagrammes. Die Aktivitäten ergeben sich durch die Methoden der Klassendiagramme.
In dem Sequenzdiagramm werden die Interaktionen zwischen konkreten Objekten und deren Nachrichtenaustausch dargestellt. Der Zeitpunkt einer Kommunikation steht in diesen szenarienorientierten Diagrammen im Vordergrund. Sequenzdiagramme gehen auf Message Sequence Charts und Event Trace Diagramme zurück.
Konsistenz zwischen Objektmodell und funktionalem Modell wird durch Verwendung von Klassen und entsprechenden Operationen aus dem Klassendiagramm erreicht. Konsistenz zwischen dynamischen und funktionalem Modell durch übereinstimmung der Aufruffolgen auf jedem Objekt mit den erlaubten Aufruffolgen im entsprechenden Statechart.
Für die Unterstützung der Softwareentwicklung steht eine Vielzahl von (Software-) Werkzeugen zur Verfügung, z.B. Editoren, Debugger, Compiler, Maskengeneratoren, Testhilfen, Projektmanagementtools etc..
Der Begriff CASE spielt dabei eine besondere Rolle. CASE steht für "Computer Aided Software Engineering", auch die umfassender Intrepretation "Computer Aided Systems Engineering" ist möglich. Darunter versteht man die teilweise oder vollständige Unterstützung des Softwareentwicklungsprozesses durch computergestützte Werkzeuge, die als CASE-Tools oder CASE-Systeme bezeichnet werden. Diese Definition ist sehr vage, im engeren Sinne könnte damit auch ein einfacher Compiler als CASE-Tool gelten. üblicherweise wird dieser Begriff aber auf komplexere Werkzeuge angewandt.
Der Nutzen des Einsatzes solcher Werkzeuge ist nach wie vor umstritten. Befürworter nenne u.A. folgende Vorteile:
Produktivitätsverbesserung
Verbesserung der Wiederverwendbarkeit
langfristige Kostenvorteile durch Senkung der Wartungskosten,
Verbesserung der Dokumentation
Erleichterung der graphischen Darstellung
An derzeit zur Verfügung stehenden Werkzeugen wird dagegen kritisiert:
Kreativitätshemmung durch Formalisierung und Kontrolle
Einschränkung auf bestimmte, meist strukturierte Methoden
mangelnder Nachweis über Kostenvorteile sowie
hohe Einführungskosten
[1] Skript; Techniken des Software-Entwurfes I, WS 98/99, Gregor Engels, Universität-GH Paderborn
[2] Skript; Wirtschaftsinformatik 4, 1998, Astrid Blumstengel, Leena Suhl, Universität-GH Paderborn
[3] Buch; Objektorientierte Softwareentwicklung, 1995, Bernd Oestereich, ISBN 3-486-23237-1
[4] Buch; The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson, 1999, ISBN 0-201-57168-4