Analyse und Design mit UML 2.3 - Objektorientierte Softwareentwicklung

1 Einführung (S. 13)

In diesem Abschnitt werden die besonderen Merkmale der objektorientierten Softwareentwicklung und der UML, ihre Historie sowie die Unterschiede zu den alten Ansätzen erörtert.

1.1 Objektorientierte Softwareentwicklung Extrakt

Softwareentwicklung wird technisch und sozial immer komplexer. Einen Spaten zum Blumenumtopfen einzusetzen ist so fehl am Platz wie ein Teelöffel zum Ausheben einer Baugrube. Auf das richtige Werkzeug und die richtige Methode kommt es an.

Softwareentwicklung wird zwar immer komplexer – aber auch immer faszinierender. Zum einen gehören Softwaresysteme zu den komplexesten von Menschen geschaffenen Systemen, zum anderen wird (anspruchsvolle) Softwareentwicklung nie langweilig – sie erfordert viel: Kreativität, Präzision, Lernfähigkeit und die Bereitschaft, immer wieder neue Sachverhalte zu durchdringen und intelligent zu strukturieren, effektiv zu kommunizieren (im Entwicklungsteam untereinander, mit dem Auftraggeber, den Anwendern u.a.), Kenntnisse und Erfahrungen im Umgang mit Vorgehensweisen, Methoden, Techniken und Werkzeugen, den souveränen Umgang mit offenen Fragen, halb ausgegorenen Vorstellungen und so weiter.

Wie Analyse und Design betrieben werden sollten, darüber gibt es sehr unterschiedliche Auffassungen, was sich in entsprechenden Vorgehensmodellen und Methoden widerspiegelt. Von sehr formalen oder schwergewichtigen Ansätzen wie V-Modell oder Rational Unfied Process (RUP) bis zu sehr pragmatischen oder einfachen Ansätzen wie beispielsweise Extreme Programming (XP), Scrum und APM.

In dem vorliegenden Buch finden Sie einen Mittelweg, der sich an agiler Modellierung orientiert, ohne jedoch eine systematische und auch für größere Projekte und Organisationen praktizierbare Analyse- und Designmethodik aufzugeben.

Technische Komplexität. Software wird nie ganz fertig. Es bleibt immer noch etwas zu ändern, zu verbessern. Und wenn Änderungen nicht zwingend notwendig sind, bleiben sie oft trotzdem wünschenswert – so lange, bis das Programm wieder aus dem Verkehr gezogen wird. Eine Vielzahl von Änderungen und Erweiterungen bewirkt natürlich, dass sich das Programm immer mehr vom ursprünglichen Konzept entfernt. Gerade wenn das Programm erfolgreich ist und deswegen ständig weiterentwickelt wird, besteht diese Gefahr.

Aus diesen Gründen ist es sinnvoll, sich nach geeigneten Methoden umzusehen, die die Komplexität beherrschbar machen, den Zerfallsprozess zumindest verzögern und trotz strukturzersetzender Änderungen und Weiterentwicklungen dabei helfen, die Qualität und Zuverlässigkeit der Software auf- rechtzuerhalten. Hier gibt es zwei sich ergänzende Ansätze, die regelmäßige Restrukturierung (Refactoring) und die Abstraktion.

Die Geschichte der Softwareentwicklung ist eine kontinuierliche Steigerung der Abstraktionen – vom Bitmuster über Makrobefehle, Prozeduren, abstrakte Datentypen zu Objekten, Rahmenwerken, Entwurfsmustern, Komponenten, generativen Verfahren bis hin zur modellgetriebenen Architektur (MDA).

Die Objektorientierung bildet hier seit Anfang der 1990er Jahre eine Basistechnologie. Die im Vergleich zu prozeduralen Ansätzen wesentlich höheren Abstraktionsmöglichkeiten der Objektorientierung gründen sich dabei nicht nur einfach auf eine Verbesserung und Weiterentwicklung der klassischen Methoden, sie begründet auch eine neue Denkweise.

Die anfangs verbreitete Vorstellung, mit Objektorientierung wird Softwareentwicklung einfacher, schneller und günstiger hat sich sehr bald als naiv herausgestellt. Stattdessen brachte die Objektorientierung viele neue herausfordernde Lern- und Erfahrungsfelder hervor.

So ist es in mehrschichtigen objektorientierten Architekturen gängig, viele verschiedene Arten von Klassen zu unterscheiden, beispielsweise Entities, Controller, Use-Case- Controller, Workflow-Controller, Datentransferobjekte, Proxies usw.

Soziale Komplexität. Die weit verbreitete Ansicht, Softwareentwicklung sei in erster Linie eine technische Aufgabe, entpuppt sich bei näherer Betrachtung des Entwicklungsprozesses als die halbe Wahrheit. Softwareentwicklung ist auch ein komplexer sozialer Prozess.