15 Jahre OMG-Standard: Unified Modeling Language (UML)

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

In diesen Tagen jährt sich die Verabschiedung Unified Modeling Language (UML) als offizieller Standard der Object Management Group (OMG) zum 15. Mal. Am 25. September 1997 wurde die UML Version 1.1 von der OMG OA&D-Task-Force zu Annahme empfohlen.

Die Entwicklung der UML war damals insofern ein bedeutender Schritt, als es zuvor Dutzende konkurrierende Notationen und Methoden im Bereich der objektorientierten Softwareentwicklung gab. Neben den drei Amigos waren damals Rebecca Wirfs-Brock, Sally Shlaer, Stephen Mellor, Adele Goldberg, Ward Cunningham, Edward Yourdon und Peter Coad die bekanntesten AutorInnen. Mit der Akzeptanz durch die OMG wurde die Weiterentwicklung dann auch von den ursprünglichen Privatpersonen an eine Industrieorganisation übertragen. Was schließlich am 20.10.2000 dann dazu führte, dass die UML auch ISO-Standard wurde.

Aus Anlass des aktuellen Jubiläums habe ich heute mal in mein Bücherregal geblickt und mir mal die erste Auflage meines orangenen Buches gegriffen. Einige erinnern sich vielleicht noch an so überaus belanglose Streitpunkte, ob Klassen nun als Wolken oder Rechtecke notiert werden sollten. Die erste Auflage von 1995 basierte noch auf der „OOD-Methode“ von Grady Booch und war voller Wolken, ab der zweiten (1997) gab es dann die UML mit den Rechtecken.
Insgesamt war die damalige Notationsblüte hilfreich, um verschiedene Ideen zu erproben und zu vergleichen. Und der geschickte Schachzug von Grady Booch, James Rumbaugh und Ivar Jacobson, sich zusammen zu tun und zu einigen, war dann ebenso hilfreich, um die Welt der inkompatiblen Modellierungsansätze wieder übersichtlicher und damit allgemein anwendbarer zu gestalten.

Der neue Standard war dann wiederum der Start für den Wettbewerb von ungezählten Anbietern von Modellierungswerkzeugen. Die Liste der UML-Werkzeuge ist nach wie vor umfangreich, bei oose pflegen wir immer noch eine Werkzeugübersicht auf unseren Internetseiten. Hier war in den ersten Jahren Rational, dann von IBM gekauft, ein wichtiger Orientierungspunkt, da Rational/IBM alle drei Amigos in ihre Nähe ziehen konnte.
Nachdem der Standard mit einem bereits großen Umfang an Diagrammtypen und Modellierungselementen gestartet ist, wuchs dieser dann in den darauffolgenden Jahren noch weiter an. Die Version 2.0 uferte aus, was nur einige wenige spezielle Anwender freute und alle anderen eher nervte, weil der Standard immer komplizierter wurde.

Mit der Version 2.0 wurde dann 2004 auch das dreistufige Zertifizierungsprogramm „OMG Certified UML Professional (OCUP)“ eingeführt. Ich erinnere mich noch, wie wir (oose) auf der OOP in München in Anwesenheit vom OMG-Chef Richard Soley den weltweit ersten Absolventen die Urkunden übergeben konnten. Tim Weilkiens und mir bot OCUP die Möglichkeit, noch eine ganze Reihe Test-Vorbereitungsbücher zu verfassen. Während ich für ein anderes Buch schon mal 5 Jahre gebraucht hatte, konnten Tim und ich das Buch zur Fundamental-Stufe dank der Materialien aus den Vorbereitungskursen in nur 4 Wochen schreiben. Was aber auch deutlich macht, dass es dabei um keine großartigen kreativen Leistungen ging, sondern ganz schlicht darum, eine gegebene und standardisierte Portion trockenen Wissens zum Lernen bereitzustellen. Aktuell sind alle drei Stufen in einem Vorbereitungsbuch zusammengefasst.

Bis heute bin ich der Meinung, das über 80 Prozent der UML-Anwender mit weniger als 20 Prozent des Standardumfanges gut auskommen würden. Ein Systemkontextdiagramm zu Anfang zu entwickeln ist immer noch hilfreich. Den Kern bilden Klassendiagramme und Aktivitätsdiagramme um die statischen und dynamischen Aspekte zu beschreiben. Damit kommen die meisten ganz gut aus.

Bedarfsweise vielleicht mal ein Sequenzdiagramm, um dynamische Aspekte besser zu durchdringen. Und für das Design im Großen, die Komponentenarchitektur, haben sich Kompositionsstrukturdiagramme bewährt.
Die Anwendungsfalldiagramme wiederum lenkten etwas von den eigentlichen Anwendungsfällen an sich ab. Um Anwendungsfälle zu beschreiben braucht es weniger eine klare und strenge Notation, als vielmehr eine einfache Schablone und vor allem sprachliche, kommunikative und soziale Befähigungen, was uns bei oose vor rund 10 Jahren motivierte, die ersten spezialisierten Fortbildungsangebote zu solchen „Soft Skills“ zu entwickeln. Die Formalisierung der Use Cases speziell durch die Diagramme war hier etwas überbetont, weswegen sich die kleine Schwester des Anwendungsfalles, die Benutzergeschichte, mit ihrer einfachen Phrasenkomposition schnell auch großer Beliebtheit erfreute.

Die UML wurde schließlich im Laufe der Jahre auch Basis für andere Notationen und Methoden: Neben dem Rational Unified Process (RUP), dem Object Engineering Process (OEP) und anderen Vorgehensmodellen, von denen heute keiner mehr spricht, beispielsweise auch für die modellgetriebene Softwareentwicklung und die Systems Modeling Language (SysML).

Die UML wird heute kaum noch thematisiert, sie ist einfach ein weltweit etablierter und verbreiteter Standard und als solcher eine Selbstverständlichkeit geworden. Ein Handwerkszeug, dass man zumindest grundlegend kennen sollte und dann bedarfsweise anwendet.

Nach 15 Jahren ist die UML nunmehr bei Version 2.5 angekommen – gerade in der letzten Woche ist die mittlerweile 10. Auflage meines Klassikers „Analyse und Design mit der UML – Objektorientierte Softwareentwicklung“ erschienen. Ich selbst bin am Thema UML schon lange nicht mehr direkt dran und werde hier immer wieder von den oose-Kollegen unterstützt, aktuell von Axel Scheithauer, der gerade dabei ist, dieses bereits seit über 17 Jahren erfolgreiche UML-Buch für die 11. Auflage rundum zu erneuern.

Die Version 2.5 stellt übrigens eine Vereinfachung der UML dar und ist das Ergebnis der UML Simplification Task Force. Vereinfacht wurde das Metamodell, so dass sich für UML-Anwender und für die 10. Auflage unseres Buches keine großen Veränderungen ergeben.

Dieser Text ist in ähnlicher Form heute auch als Online-Artikel bei Heise Developer erschienen.