"Ein Bild sagt mehr als tausend Worte."
(Deutscher Volksmund)

UML

Die "Unified Modeling Language" (dt.: "vereinheitlichte Modellierungssprache", UML [L11]) wurde von der Object Management Group (OMG [L3]) am 17.11.1997 in der Version 1.1 als Standard verabschiedet. Die UML bietet Möglichkeiten, um von der ersten Aufnahme eines Geschäftsprozesses über die Analyse von Anwendungsfällen bis zum Entwurf von Klassendiagrammen und Aktivitätendiagrammen lückenlos graphisch arbeiten zu können. "Zur Zeit sprechen alle Anzeichen dafür, dass die UML die Notation der Zukunft für die Objektorientierung wird." [B7]. Ein UML-Beispiel haben Sie bereits mit dem Zustandsdiagramm auf der vorherigen Seite am rechten Rand gesehen.

Der Vorteil von der Anwendung der UML liegt in der graphischen Notation. Im Gegensatz zu einem Prosatext, den Sie nur von links oben nach rechts unten lesen können, haben Sie bei vielen Diagrammformen die Möglichkeit, an mehreren Stellen einzusteigen und das Diagramm in verschiedene Richtungen zu diskutieren. Statt sequentiell kann hier flächig gedacht, diskutiert und gearbeitet werden. Vielleicht haben Sie selbst schon einmal am Flipchart die Erfahrung gemacht, dass die Entwicklung einer Mindmap viel einfacher ist als die Entwicklung einer Liste. Falls nicht, kann ich es Ihnen nur empfehlen. Wir sind zwar alle durch unsere schulische Ausbildung dazu verzogen, mit einem Stift auf dem Papier einen Aufsatz, ein Diktat, eine Übersetzung, eine Liste oder gar einen mathematischen Beweis von links oben nach rechts unten aufzuschreiben, aber wenn Sie sich davon testweise lösen können, um mal in einer Form zu notieren, wie Gehirnforscher sie als passender für uns herausgefunden haben, werden Sie es vielleicht mögen. Nebenstehend sehen Sie, wie ich das Inhaltsverzeichnis dieser Abhandlung als Mindmap entwickelt habe - es gibt natürlich auch längst Software dafür [L18].

Die Mindmap ist kein Diagrammtyp der UML, aber die graphische Denk- und Arbeitsweise haben beide gemeinsam. So können Sie bei der Sammlung der Anforderungen in Kundengesprächen durch Notieren der Gedanken in einer Mindmap auf dem Whiteboard bereits eine erste Struktur in die Gedanken bringen und Schwerpunkte erkennen. Oft ergibt sich sogar schon eine mehrstufige Hierarchie. Sie können natürlich zusätzlich aufschreiben, welcher Gedanke von wem kam. Nach Diskussionen können Sie einige der notierten Gedanken an den Ästen vielleicht direkt schon mit "IN" oder "OUT" kennzeichnen, weil schon definitiv abgegrenzt werden kann, ob diese Anforderungen abgedeckt werden sollen oder nicht. Und Sie werden sehen, dass Sie noch immer den Überlick behalten (zumindest, wenn Sie etwas großzügiger gezeichnet haben).

Von dieser Mindmap können Sie direkt ein "Purpose and Scope"-Diagramm ableiten, in dem die Akteure des geplanten Systems als Strichmännchen eingezeichnet werden und deren Anforderungen an das System mit Pfeilen dargestellt werden. Damit kann halt der Zweck des Systems und auch die Tragweite des Systems im Unternehmen sehr schön dargestellt werden. Dies ist bereits ein UML-Diagramm und die Erstellung am PC wird von vielen Tools unterstützt. Daraus können auch direkt Fälle abgeleitet werden, für die das System angewendet werden soll, sogenannte "Anwendungsfälle", die in eine Kopie des soeben geschilderten Diagramms eingezeichnet werden können. Aus einer Hierarchie der Anwendungsfälle können erste Menüstrukturen entstehen. Hier werden auch die Teilziele des neuen Systems fixiert. Aus dem Anwendungsfalldiagramm kann in einer weiteren Iteration in der Designphase durch ergänzende Informationen aus dem Prototypen und dem Prosatext eine erste Klassenstruktur abgeleitet werden, die in eine echte Klassenhierarchie weiter entwickelt werden kann. Darin kann eine Klassifizierung der Klassen vorgenommen werden, wodurch sich die Verteilung der Komponenten auf die "tier" (dt.: etwa "Schichten" oder "Säulen") ergibt. Dadurch entsteht ein erster Architekturentwurf. All diese Diagramme können mit der UML-Notation erstellt werden und bei UML 2.0 auch teilweise ineinander überführt werden.

So unterstützt uns die graphische Notation der UML von der ersten Ideensammlung bis hin zur fertigen Klassenhierarchie und weiter. Dies kann zur Zeit kein Prosatext, kein Prototyp, keine Programmiersprache und kein anderes Instrument leisten, weil diese immer nur bestimmte Phasen der Entwicklung abdecken. Aber gerade deshalb sind sie zur Ergänzung auch so wichtig, weil ein UML-Diagramm nämlich wiederum nicht einen Prosatext oder einen Prototyp oder die Programmierung ersetzen kann. UML formuliert den roten Faden durch den gesamten Entwicklungszyklus und sollte auch genau so gesehen werden. Es ist kein Allheilmittel, es ist nichts, was man ausschließlich einsetzen sollte und es löst nicht alle Probleme. Es ist lediglich eine Sprache, mit der man sehr viele Aspekte des Entwicklerlebens darstellen und ineinander überführen kann - Punkt.

Es gibt zahlreiche Bücher, die UML verheiligen und die Bedeutungen der graphischen Symbole bis ins letzte Detail auf vielen hundert Seiten erläutern, aber finden Sie mal ein Buch, welches Ihnen an praktischen Beispielen verrät, wann Sie welches Diagramm wie einsetzen sollten und vor allem: Wie kommen Sie mit den Diagrammen von einer Phase oder Iteration zur nächsten? Wie ein Anwendungsfalldiagramm aussieht, können Sie nachlesen, wie ein Klassendiagramm aussehen sollte, finden Sie an jeder Ecke; aber wie überführen Sie beispielsweise als Designer oder Entwickler ein Anwendungsfalldiagramm, das von einem Analytiker mit Fachleuten zusammen entwickelt wurde, in ein Klassendiagramm? Und ich rede hier gar nicht mal von Software-Tools! Und dann kommt das spannende Thema "Reverse-Engineering", also die Rückwärtsentwicklung: Angenommen, ein Entwickler stellt bei der Implementierung einen Widerspruch fest (was ja durchaus vorkommt) und ist tatsächlich so offen, kommunikativ und weitsichtig, dieses seinem Designer anzuzeigen. Wie wird das ins Klassendiagramm integriert, um es ins Anwendungsfalldiagramm zurück zu abstrahieren und in den Prosatext und Prototypen einzubringen, um es dann mit dem Kunden zu diskutieren? Da wird die Luft schnell dünn! Ich werde in dieser Abhandlung einige dieser Aspekte abdecken, da ich selbst schon häufig in verschiedenen Projektrollen vor diesen Problemen stand und dafür auch gemeinsam mit meinen jeweiligen Teams Lösungen entwickeln konnte.

Während UML 1.x schon umfangreich war und eine enorme Vielfalt bot, haben sich einige Dinge mit UML 2.0 auch noch grundlegend geändert. Außerdem ist UML mit der neuen Version 2.0 wegen der weiteren Formalisierung noch umfangreicher geworden. Neben dem verbesserten Modellaustausch über XMI (XML Metadata Interchange) und einer erweiterten Unterstützung der MDA (Model Driven Architecture) sowie einer besseren Unterstützung des BPM (Business Proecess Modeling) gibt es jetzt endlich auch eine bessere Unterstützung für RTM (Real Time Modeling) mit neuen Diagrammtypen. Bei Aktivitätsdiagrammen hat sich die Sicht völlig geändert, weil diese jetzt nicht mehr als eine Spezialform der Zustandsdiagramme gesehen werden sollen. Sequenzdiagramme kennen jetzt auch Unterdiagramme und Schleifenkonstrukte.

Wenn Sie jetzt nicht alles direkt nachvollziehen konnten, ist das überhaupt nicht schlimm, denn wir sind ja hier im Kapitel "Vorgehensweise", wo ich zunächst nur einmal einen Überblick über die Ausgangssituation, die Aufgabenstellung sowie einen praktischen Weg gebe. Genauer: wir sind hier auf einer Seite, auf der ich den Sinn und Unsinn von UML ganz kurz abgrenze, weil das Thema einfach nach wie vor mega-hip ist. In den nächsten Kapiteln wird Alles nach und nach verfeinert und - soweit unsere Kunden einverstanden sind - mit Beispielen belegt.

Sie finden übrigens alle Originaldokumente zur UML bei der OMG selbst [L11]. Falls Sie statt der Online-Spezifikation ein echtes Buch aus echtem Papier bevorzugen, empfehle ich [B2] und [B13]. Die UML hängt immer stark mit den "drei Amigos" der Firma Rational [L7] zusammen, weil diese den Vorschlag über mehrere Jahre ausgearbeitet und bei der OMG zur Standardisierung eingereicht haben. Mittlerweile ist Rational von IBM übernommen worden. Ich kann Ihnen übrigens nur wärmstens den monatlichen Report "The Rational Edge" [L19] empfehlen!