Die Anwendung von Software in irgendeiner Form ist heutzutage bereits fester Bestandteil des täglichen Lebens. Und so hat auch schon jeder seine Erfahrung mit dieser nicht sichtbaren aber doch zum Teil sehr wirksamen und hilfreichen Form elektronisch gespeicherter Handlungsvorgaben gemacht. Derartige, überwiegend positive Erfahrungen sind beispielsweise
die schnelle und durch eine automatisierte (software-gestützte) Rechtschreibkontrolle korrekte Erstellung eines Manuskriptes, Briefes oder einer Titelsammlung mit einem Textverarbeitungssystem,
die komfortable Führung bei der Informationssuche (beispielsweise in einem Museum) mittels eines Touchscreens auf der Grundlage eines wissensbasierten Software-Systems,
die beeindruckenden Animationseffekte in Filmen durch die bildverarbeitende und bilderzeugende Software,
die teilweise emotionale Reaktion auf einen Schachzug des Computers beim Spiel mit einem Schachprogramm,
das „Surfen“ durch das Internet und das Gefühl, aufgrund von Suchmaschinen überall präsent sein und alles einsehen zu können,
das faszinierende Navigieren in virtuellen Welten mittels Cyberhead und der 3D-visualisierten Simulationssoftware.
Die schnelle Verbreitung der Anwendungstechnologien und -felder für Software-Systeme erschwert eine allgemeingültige Klassifikation dieser Systeme. Die internationalen Normungsgremien haben hierbei keine den aktuellen Erfordernissen entsprechende Dokumente vorzuweisen. Auch die „Encyclopedia of Software Engineering“ enthält keine explizite Einteilung. In der Software-Engineering-Literatur werden derartige Klassifikationen zumeist zur Abgrenzung der jeweils behandelten Technologie verwendet. Wir wollen eine Klassifikation unter dem technologischen Aspekt von [Conger 94], S. 17 ff., anführen, die Software-Systeme unterteilt in
Das folgende Kapitel widmet sich schließlich einigen Technologien zur Software-Entwicklung. Dabei wollen wir uns im Rahmen dieses Buches auf ausgewählte Formen und Methoden beschränken, die vor allem den gegenwärtigen Inhalt des Software Engineering mehr oder weniger stark prägen. Dazu zählt vor allem die objektorientierte Entwicklungsform mit ihrer speziellen Ausprägung als komponenten-basierter Technologie. Die dabei sehr starke Orientierung auf die Software-Wiederverwendung führt uns zu allgemeinen Formen und Methoden des Software-Reengineering.
Die nahezu verbreitetste Form objektorientierter Software-Entwicklung wird gegenwärtig durch die UML (Unified Modeling Language) initiiert. UML ist bei der Firma Rational Rose aus den folgende Methoden bzw. Techniken der sogenannten „Amigos“ (Booch, Rumbaugh und Jacobson) hervorgegangen (siehe [Booch 99], [Jacobson 99] und [Rumbaugh 99] bzw. unter „http://www.omg.org“):
OMT als vormals weitverbreitetste OO-Methode mit ihrem Klassendiagramm (siehe Abschnitt 3.1 bzw. [Rumbaugh 93]), die allerdings noch als Einstieg ein Datenflussdiagramm (siehe Abschnitt 2.2) hatte,
OOD für die Komponenten- bzw. Architekturdarstellung in der Entwurfs- und Implementationsphase als Komponenten- und Verteilungsdiagramm (siehe Abschnitt 1.2.5 bzw. [Booch 91]),
OOSE mit dem Use-Case-Diagramm für den Entwicklungseinstieg (siehe Abschnitt 1.3) und die Interaktions- bzw. Sequenzdiagramme für die Kommunikationsbeschreibung (siehe Abschnitt 2.5 bzw. [Jacobson 92]),
die sogenannten Zustandsdiagramme von Harel (siehe Abschnitt 2.4 bzw. [Harel 92]) und die zeitbezogene Funktionsdarstellung als Aktivitätsdiagramm (siehe Abschnitt 2.3),
die sogenannten CRC-Karten der RDD-Methode, die heute allerdings weniger zur Anwendung kommen (siehe [Wirfs-Brock 93]),
den allgemeinen Erfahrungen, die bereits bei einer mehrjährigen OO-Software-Entwicklung gesammelt wurden (siehe [Berard 93], [Cockburn 98], [Lorenz 93] oder unter „http://wwww.eetoolbox.com/softdv/obsject.htm“), wie beispielsweise
die stärkere Beachtung der Verhaltensdarstellung im Zusammenhang mit der statischen Klassenbeschreibung,
die Notwendigkeit der Unterstützung für eine problembezogene Suche in Klassenbibliotheken,
die größre Unterstützung für den weitaus komplizierteren Integrationstest beim OOP im Verhältnis zur klassischen Systementwicklung.
