2. Die Ursachen 

Die UML ist eine Methode, die gleichermaßen die Anforderungen der Analyse, der Spezifikation, des Designs und der Entwicklung bedienen sollte. Darüber hinaus sollten die Ergebnisse der Methode interoperabel und austauschbar sein. Das Augenmerk ist dabei hauptsächlich auf die Erleichterung der Produktion, nicht aber auf den Gebrauch der Ergebnisse gelegt worden.

Die daraus resultierenden Design-Entscheidungen sind im Blick auf die Bedingungen am Anfang der 90er Jahre gerechtfertigt gewesen. Heute haben sich die Gewichte jedoch deutlich verschoben. So geht zum Beispiel der Erfolg von Java mit einer ständig wachsenden Klassenbibliothek einher. Dabei stehen jedem Bibliotheksentwickler Tausende von Anwendern gegenüber. Der Segen der Wiederverwendung hat zur Folge, daß ein Verfahren, welches das Leben der Anwender auch nur um 1 Prozent erleichtert, genauso wirkungsvoll ist, wie ein Verfahren, welches die Produktivität der Systemprogrammierer um das Zehnfache steigert. Dieser Trend wird sich auch in Zukunft weiter fortsetzen. Die Arbeit der Programmierer wird immer mehr durch das Erlernen und Verwenden der Ergebnisse Anderer bestimmt werden. Umgekehrt wird es aber auch für die Bibliotheksentwickler immer wichtiger werden, eine gute Dokumentation zu erzeugen. Im Genpool aller Klassen wird nur der Code häufig verwendet, der effektiv dokumentiert wurde. Und nur die häufig verwendeten Klassen werden im Wettbewerb der Klassen um Anwender letztendlich überleben.

Ein Beispiel für ein Design-Tradeoff im UML-Entwurf ist das völlige Fehlen der Berücksichtigung von Flächen, Farben, Texturen und Schriftstilen. Das einzige graphische UML-Element ist die Linie. Ein Grund hierfür mag gewesen sein, daß man UML-Diagramme jederzeit auch mit Stift und Papier erzeugen können sollte. Das Ergebnis dieser Beschränkung ist eine visuelle Attraktivität, die nicht einmal dem Niveau von DOS-Programmen nahe kommt. Zum Beispiel erfolgt die Unterscheidung zwischen Klassen und Interfaces lediglich durch eine stereotype <>- Beschriftung, obwohl sich ein farbiger Hintergrund viel besser zur Unterscheidung solcher diskreter Kategorien eignen würde.

Darüber hinaus scheint die UML-Definition hauptsächlich ein Werk von Programmierern gewesen zu sein. Graphikdesigner dürften wohl kaum eine wichtige Rolle gespielt haben. So sind zum Beispiel so wichtige Designkonzepte wie Kontrast, Ausrichtung, Wiederholung und Nachbarschaft nirgends berücksichtigt. Eine gute Diskussion dieser Konzepte findet man bei Robin Williams [4].

Auch moderne Erkenntnisse der Wahrnehmungspsychologie haben keinen Eingang in die Spezifikation gefunden. So wird zum Beispiel die Richtung einer Vererbungsbeziehung durch eine Linie mit Pfeilspitzen gekennzeichnet. Dazu ist zunächst zu sagen, daß es nicht intuitiv erfaßbar ist, ob der Ober- oder der Untertyp Ziel der Spitze sein muß. Auf die Dauer wiegt aber schwerer, daß man die Bedeutung einer Beziehung nicht mit einem Blick erfassen kann. Das Auge des Betrachters muß die Linie in ihrer ganzen Länge verfolgen, um zu entscheiden, welcher Art die Beziehung ist.

Ein Beispiel für ein Design-Tradeoff, das aus der Austauschbarkeit resultiert, ist das Vertauschen der Signaturen. Statt der in C oder Java üblichen Reihenfolge

    Typ Name

    Name : Typ

    List subList (int fromIndex, int toIndex)

    subList (fromIndex: int, toIndex: int) : List

Ein weiterer Grund für die mangelhafte Darstellung von UML liegt in dem Irrglauben begründet, daß Diagramme rein automatisch erzeugt werden können. Während es sich allgemein durchgesetzt hat, daß maschinell erzeugte Texte nur selten einen wirklichen Nutzen für das Publikum haben (Bild 2), wird der Anspruch bei Diagrammen noch aufrechterhalten. Tatsächlich ist die effektive Darstellung von Baumdiagrammen seit Jahren Gegenstand internationaler wissenschaftlicher Konferenzen [5].

Boss:     I have an Idea!
          We’ll automate our online tech support.
          Our software will analyze incoming e-mail
          and send responses based on keywords!
Dilbert:  That’s an excellent plan.
Boss:     I know.
Dilbert:  But what about the one percent of our customers
          who actually get a useful response?
          Maybe we could wear ski masks and throw rocks at their houses.
          Then we could achieve our goal of 100% Customer dissatisfaction!
          Woo Hoo!
Dilbert:  (thinks) Maybe I should work somewhere else.

Bild 2: Text eines Dilbert[6]-Cartoons.

Bereits die Auswahl der Informationen, die für ein Diagramm nötig sind, ist eine besondere intellektuelle Fähigkeit, die bisher nur von Menschen erbracht werden kann. Tatsächlich wurde auch schon für das Klassendiagramm von TogetherJ eine Vorauswahl getroffen. Das Diagramm wäre noch weitaus komplizierter geworden, wenn alle 60 Klassen aus dem Package "java.util" dargestellt worden wären.

 1. Das Problem
 3. Die Lösung