Die Methoden der Objektorientierung (OO) und die zugehörige Notation Unified Modeling Language (UML) sind schon in vielen Unternehmen im Einsatz. In anderen werden sie heiß diskutiert. Um entscheiden zu können, ob die Einführung einen entscheidenden Vorteil bringt und welche Risiken dafür in Kauf genommen werden, sollte der CIO oder IT-Manager ein paar grundlegende Dinge über OO und UML wissen.
Sieben Stolpersteine
1. Konzeptionelle Risiken (unrealistisch hohe Erwartungen).
2. Politische Risiken (Widerstand gegen die Einführung).
3. Management-Fehler (schlechte Schulung der Mitarbeiter).
4. Analyse- und Designfehler (falscher Einsatz der Methoden).
5. Implementierungsfehler (vor allem der, zu früh mit der Implementierung zu beginnen).
6. Qualitätssicherungs-Fallen (also Vernachlässigung der Qualitätssicherung).
7. Unreflektierte Annahme des neuen Vorgehens (fehlendes Hinterfragen).
Die Vorteile der OO im Überblick
Modelle und teilweise sogar Codierungen lassen sich mehrfach verwenden. Das spart Aufwand.
Konzepte und Notationen ziehen sich ohne Brüche durch alle Stufen des Entwicklungsprozesses.
Klare Schnittstellen machen das System offen für Erweiterungen; die Änderungen bleiben aber lokal (Open-Close-Prinzip).
Frühes Prototyping und damit Transparenz für den Auftraggeber sind erst möglich durch Realitätsnähe und modellbasierende Entwicklung.
Einfaches Änderungs-Management und Wiederverwendbarkeit der Objekte machen das System leichter wartbar.
Fazit
Ein Paradigmenwechsel bedeutet kurzfristig immer Mehraufwand. Mit der Zeit und den gesammelten Erfahrungen lohnt sich der Methodenwechsel auf OO und UML aber in jedem Fall. Den Risiken stehen deutliche Vorteile gegenüber, die sich am Ende auch in Euro und Cent niederschlagen werden.
Wo der Begriff OO ursprünglich herkommt
Der Begriff Objektorientierung entstammt ursprünglich der Softwareprogrammierung. Er bezeichnet die Abkehr vom prozeduralen Programmieren, bei dem die Probleme durch Funktionen gelöst werden. Stattdessen sollte ein Abbild des Systems erstellt werden, das Lösungen über bestimmte Fähigkeiten bietet. Ziel war es, die Programme verständlicher und damit wartbarer zu machen.
Die angesprochenen Fähigkeiten des Systems entstehen durch die Kooperation von Objekten. Also müssen sich die Entwickler überlegen, welche Objekte innerhalb des Systems entweder im Alleingang oder in der Zusammenarbeit solche Fähigkeiten erzeugen. Diese Objekte haben neben ihren Fähigkeiten auch Eigenschaften. Zudem stehen sie in Beziehungen. Sowohl die Objekte selbst als auch deren Beziehungen sind in den objektorientierten Methoden Gegenstand der Betrachtung. Damit bei der großen Zahl von Objekten in einem System der Überblick nicht verloren geht, werden sie zu Klassen zusammengefasst.
Ein Beispiel zur Veranschaulichung
Dazu ein Beispiel aus der Architektur: Ein Haus besteht aus mehreren Teilen, die beispielsweise den Klassen Wand, Tür, Fenster angehören, aber die Einzelausprägung Eingangs- oder Küchentür haben. Die Klassen ermöglichen die fachliche Strukturierung des Systems. Nicht nur die Objekte, auch die Klassen haben Eigenschaften und Fähigkeiten. Zum Beispiel besitzt eine Tür ein Schloss, sie lässt sich öffnen oder schließen.
Darüber hinaus bietet die OO weitere Möglichkeiten, die Sichtweise auf das System zu vereinbaren. So können neben einfachen Beziehungen zwischen den Klassen auch Zusammengehörigkeiten erkannt und die Klassen in Spezialklassen unterteilt werden. Spezialklassen "erben" die Eigenschaften und Fähigkeiten der Oberklasse, können aber zusätzliche Eigenschaften und Fähigkeiten bekommen. Beispielsweise haben Eingangstüren alle Eigenschaften einer normalen Tür, darüber hinaus aber ein einbruchssicheres Schloss statt eines normalen Türschlosses.
Objektorientierte Analyse und OO-Design
Inzwischen wird OO nicht erst bei der Programmierung angewandt. Vielmehr kommt sie schon in der objektorientierten Analyse (OOA) und beim objektorientierten Design (OOD) zur Anwendung.
Eine gute Anforderungsspezifikation im Rahmen der Analyse ist wegen der immer umfangreicher und komplexer werdenden Systeme heute eine echte Herausforderung. Hier kann die OOA helfen. Für sie gelten dieselben Regeln wie für die OO im Allgemeinen, wobei der Fokus in der Analysephase auf dem "Was" liegt.
Die Anforderungen an das System orientieren sich an den Aufgaben, den Objekten und Klassen sowie deren "Umgangsformen". Die objektorientierte Analyse erlaubt es, die Aufgaben des Systems auf einzelne Objekte zu verteilen, und ermöglicht es deshalb, die Anforderungen sehr präzise darzustellen.
Diese Objekte resultieren aus dem "Begriffsmodell", das die für das System relevanten Begriffe der Anwendungsdomäne als Klassen und deren Zusammenhänge darstellt. Vor diesem Schritt werden häufig Anwendungsfälle des Systems modelliert, um mit ihrer Hilfe die einzelnen Aufgaben beziehungsweise Funktionen des Systems zu beschreiben. Diese Anwendungsfälle sind nicht im eigentlichen Sinn objektorientiert, sie zählen jedoch mit zur OOA.
Die UML beugt Missverständnissen vor
Die Softwareentwicklung kennt die Notation von Arbeitsergebnissen in reiner Textform. Daneben werden aber häufig auch Modelle oder Diagramme genutzt, denn diese Art der Dokumentation ist übersichtlicher und lässt sich einfacher verstehen. Um das von den Entwicklern erhobene Wissen grafisch darzustellen, ist jedoch eine genormte Notation nötig. In der OO kommt hier die Unified Modeling Language, kurz UML, zum Einsatz.
Eine derartige Notation ist immer dann wichtig, wenn es um die Schnittstelle zwischen Personen geht, vor allem dann, wenn das Entwicklungsprojekt in einem Auftraggeber-Auftragnehmer-Verhältnis abläuft. Die beiden Parteien sollten sich frühzeitig auf diese Darstellungsform einigen, damit sie nicht aneinander vorbeireden. Sonst entstehen Missverständnisse mit der Folge, dass Fehler erst in der Realisierungsphase oder noch später aufgedeckt werden. Kurz gesagt: Die UML unterstützt das Projekt, indem sie das Wissen über das System allen Projektbeteiligten verständlich macht, also hilft, Kommunikationsprobleme zu vermeiden oder zu beseitigen.
Durchgängig auf allen Abstraktionsebenen
Innerhalb der UML gibt es verschiedene Möglichkeiten der Darstellung: auf sehr abstrakter Ebene (zum Beispiel als Use Cases) für das Management oder als grober Einstieg, aber auch als detaillierte Darstellung hinsichtlich der Kommunikation (beispielsweise mit Sequenzdiagrammen) oder des Verhaltens (zum Beispiel mit Zustandsautomaten) einzelner Objekte. Auf der Grundlage dieser Modelle lassen sich dem jeweiligen Diagramm bei Bedarf auch natürlichsprachliche Anforderungen zuordnen.
Projekte scheitern oft in der Analysephase. Das liegt dann an unklaren, "schlechten" und unstrukturierten Anforderungen. Sie führen dazu, dass der Programmierer nicht weiß, was er implementieren soll. Auch dem Kunden selbst ist oft nicht klar, ob in dem Anforderungsdokument auch das steht, was er in Auftrag geben will. Oft hat er in den seitenlangen Beschreibungen den Überblick verloren.
Eine der wichtigsten Fragen der Systementwicklung lautet demnach: "Wie erhebe und dokumentiere ich die Anforderungen so, dass sie für alle Projektbeteiligten verständlich sind?" Die Management-Ebene ist ja darauf angewiesen, dass die Darstellung abstrakt und intuitiv verständlich ist. Der Programmierer hingegen benötigt eine detaillierte und feingranulare Dokumentation, die wenige Fragen offen lässt.
Der Einsatz von OO und UML erlaubt eine durchgängige Beschreibung eines Systems auf unterschiedlichen Abstraktionsebenen. So ist es möglich, den verschiedenen Bedürfnissen aller Beteiligten gerecht zu werden.
Vorübergehend nimmt der Aufwand zu
Allerdings bedeutet eine bessere Dokumentation mit Objektorientierung und UML auch mehr Kosten vor allem, aber nicht nur in der Phase der Anforderungsermittlung. Die gewissenhaftere Erhebung der Anforderungen zieht zwangsläufig einen Mehraufwand nach sich.
Aber die Erfahrung zeigt, dass die Kosten für Fehlerbehebung und Änderungs-Management im Vergleich zu den Erstentwicklungskosten sehr hoch sind; und je später ein Fehler entdeckt wird, desto teurer wird seine Behebung. Deshalb wird sich die kurzfristig höhere Investition in der Analysephase langfristig positiv auf den Profit und die Kundenzufriedenheit auswirken
Durch die Einführung der neuen Methodik werden die Kosten in der Einlernphase immer erst steigen. Doch nach der Einführung bleibt unter dem Strich ein deutlicher Gewinn (siehe Grafik "Investition zahlt sich aus").
Das Für wiegt das Wider in jedem Fall auf
Jede Medaille hat zwei Seiten. So hat auch die OO mögliche Nachteile. Im Zuge der Einführung einer Methode oder eines Vorgehens besteht immer die Gefahr, dass durch den übereifrigen Einsatz des neu Erlernten der Arbeitsaufwand unverhältnismäßig steigt. Leider kann die Methodik unerfahrene Anwender dazu verführen, einen zu großen Arbeits- und Dokumentationsaufwand zu betreiben. Das Projekt kann also wie bei anderen Methoden auch unter einer Papierflut ersticken. Es gilt immer abzuwägen, wie viel Aufwand nötig ist, um die Risiken der Systementwicklung zu verringern.
Hinzu kommt der ebenfalls übliche Aufwand für die Einführung selbst und die Überzeugung der Mitarbeiter. Nicht zu unterschätzen ist dabei der schwierige Umdenkprozess. Der Mensch ist nun mal ein Gewohnheitstier, das sich mit Veränderungen am Anfang immer schwertut.
Daneben birgt jede neue Methode Risiken auch die Einführung von OO und UML. Sie sind im Kasten "Sieben Stolpersteine" zusammengefasst.
Am Ende überwiegen jedoch die Vorteile der OO und der UM. Da sei zunächst die Wiederverwendbarkeit der Modelle zu nennen. In manchen Fällen ist es sogar ohne größeren Aufwand möglich, den Code wiederzuverwenden.
Zudem steht die OO für Flexibilität. Die Konzepte und Notationen gelten sowohl für den Entwurf als auch für die Implementierung; sie sind ein Spiegelbild des Programms. Die Durchgängigkeit über alle Schritte der Softwareentwicklung ist ein Hauptvorteil von OO und UML. Bei anderen Methoden klaffen oft große Lücken zwischen der Analyse, dem Entwurf und der Implementierung.
Ein OO-Ansatz folgt dem "Open-Close-Prinzip": Das System ist offen für Erweiterungen, weil die Schnittstellen klar definiert sind. Gleichzeitig ist es aufgrund seiner Struktur in sich geschlossen, also resistent gegen unerwünschte Veränderung. Selbstverständlich sind Änderungen möglich, sie werden aber lokal vorgenommen.
Da sich die Objekte und Klassen aus der Anwendungsdomäne in der Implementierung wiederfinden, ist das System "realitätsnah". Dies erlaubt zusammen mit der modellbasierenden Entwicklung ein frühes Prototyping auf Basis der UML. Besonders dann, wenn das Unternehmen die Applikationen nicht selbst umsetzt, hat es so weit bessere Möglichkeiten, den jeweiligen Ist-Stand abzurufen oder die Grundlage für die Umsetzung von Testszenarien zu schaffen.
Last, but not least erleichtert die OO die Wartbarkeit des Systems. Dafür sorgt nicht nur das einfachere Änderungs-Management, sondern auch die Wiederverwendbarkeit der Objekte. Sie ist der Garant dafür, dass sich das System unter Berücksichtigung der Schnittstellen einfach anpassen oder erweitern lässt.
Sanfte Vorgehensweise bei der Einführung
Für die Einführung empfiehlt sich im Allgemeinen eine sanfte Vorgehensweise. Beispielsweise können zunächst die wichtigsten Projektbeteiligten eine Schulung besuchen. Anschließend empfiehlt es sich, einen erfahrenen Coach zu integrieren, um zeitraubende Diskussionen und Fehlentscheidungen zu vermeiden. Nach einem ersten Projekt besitzt das Unternehmen dann erfahrene Mitarbeiter, die ihr Wissen an die Kollegen weitervermitteln können. (qua)