Frage: In welchem Stadium befindet sich die UML 2.0-Standardisierung? Kann UML 2.0 schon eingesetzt werden?

Antwort: Die Arbeiten an UML 2.0 wurden seitens der Einreicher abgeschlossen und die Spezifikation durch die Analysis and Design Task Force der OMG per Abstimmung angenommen. Ebenso hat das OMG Architecture Board die Spezifikation verabschiedet und in den Stand einer OMG Adopted Specification erhoben.
Mit dem Ende der aktiven Arbeiten und den beiden Abstimmungen hat die UML 2.0 daher ihren endgültigen Ausbaustand erreicht.
In der aktuellen Finalisierungsphase wird die durch die OMG-Gremien angenommende Spezifikation durch die Finalization Task Force überarbeitet und editorielle (hierunter fallen schlichte Tipp- und Kopierfehler) sowie kleinere technsiche Fehler behoben. Die Finalization Task Force wird jedoch keine gravierenden Änderungen (wie die Entfernung bestehender oder Hinzunahme neuer Diagrammtypen) an der bestehenden Spezifikation vornehmen.
Daher kann die Arbeit an UML 2.0 als abgeschlossen angesehen und die aktuelle Spezifikation durchaus für erste Projekte herangezogen werden. Dies illustrieren insbesondere auch Aktivitäten der seitens der Werkzeughersteller, die bereits mit der Implementierung der UML 2.0 in ihren Produkten begonnen haben.

Frage: Welche (bekannten) „Kinderkrankheiten“ der UML 2.0 besitzen das Aktivitäts-, das Sequenz- und das Aktivitätsdiagramm?

Antwort: Das Klassendiagramm weist inzwischen keine Kinderkrankheiten mehr auf. Da es als Basis der gesamten UML auch im Metamodell breite Verwendung findet und mit einer Historie, die bis in die 1970er Jahre zurückreicht, über eine lange Vorgeschichte verfügt sind dessen graphische Primitive inzwischen sehr ausgereift. Einige „klassische Schwächen“ des UML-Klassendiagramms, beispielsweise im Umfeld der Semantikdefinition von Komposition und Aggregation, sind allerdings auch kaum verändert präsent.
Die Verhaltensdiagramme hingegen verfügen über eine deutlich kürzere und gleichermaßen bewegtere Historie. Sie würden erst relativ spät in die UML integriert und in den 1.x-er Spezifikationsversion etwas stiefmütterlich behandelt. In der Version 2.0 wurden alle Diagrammtypen zur Darstellung dynamischen Verhaltens einer deutlichen Überarbeitung unterzogen, welche sich in spürbarem Mächtigkeitsgewinn auszahlt. Allerdings -- und dies bildet sicherlich die prägendste „Kinderkrankheit“ der Version 2.0 -- wurde sowohl auf die konsequente und vollständige Integration der den dynamischen Diagrammen zugrundeliegenden Bassstandards wie MSCs verzichtet, als auch innerhalb der UML keine verbindliche Semantikdefinition festgelegt.

Frage: Welche Neuerungen bei UML 2.0 haben aus Ihrer Sicht die größte Bedeutung?
Wo sehen Sie die wichtigsten Benefits für Entwickler?

Antwort: Der Standardisierungsprozess hat den Wünschen der Anwender an vielen Stellen Rechnung getragen. Gleichwohl präsentiert sich das Update auf 2.0 eher als leise Evolution denn als Revolution, da die an der Standardisierung Beteiligten der Versuchung, eine neue UML zu erfinden, widerstanden haben. In der Menge der Änderungen fallen dem Betrachter vor allem zwei Bereiche auf:
Die Änderungen an der Basis der Sprache und im Bereich der Verhaltensmodellierung.
Das Metamodell der UML wurde grundlegend überarbeitet, insbesondere wurde die semantische Beschreibung der Elemente präziser gefasst sowie Redundanzen und Inkonsistenzen beseitigt. Dadurch ist die UML ist in der neuesten Version kompakter und in sich schlüssiger geworden. Für den Anwender erleichtert dies das Erlernen und die Anwendung der UML, da die vorhandenen Basiskonzepte in verschiedenen Diagrammen mit dem gleichen Verhalten und gleicher Bedeutung eingesetzt werden können. Daneben profitieren von diesen Änderungen in besonderem Maß natürlich auch die Toolhersteller.
Anders als der Bereich der Diagramme zur statischen Modellierung, der vergleichsweise geringfügige Änderungen erfuhr, wurde der Bereich der dynamischen Diagramme einer umfangreichen Umstrukturierung und Erweiterung unterzogen. So wurde die Semantik und Notation des Aktivitäts- wie des Sequenzdiagramms völlig überarbeitet, zwei neue Sichten eingeführt (Timing- und Interaktionsübersichtsdiagramm) und das Kollaborations­diagramm wurde in Kommunikationsdiagramm umgetauft. Neue Möglichkeiten der Verhaltensmodellierung wie die Schachtelung und Vererbung von Diagrammen oder die Darstellung von verschiedenen Interaktionen in einem Diagramm unterstützen Reengineering-Ansätze und Top-Down-Vorgehensmodelle.
Mit dem Timing-Diagramm und verbesserten Modellierungsmöglichkeiten von zeitlichem Verhalten und Nebenläufigkeit in Interaktionen empfiehlt sich die UML auch stärker als bisher für die Modellierung in der Geschäftsprozessanalyse oder von Systemen im technischen Umfeld. Schließlich verbessern neue Kontrollstrukturen und das von den Petri-Netzen entliehene Tokenkonzept im Aktivitätsdiagramm die Möglichkeiten des Anwenders, Abläufe gezielter zu steuern. Abläufe sind nun durch geeignete Werkzeuge simulierbar und können beispielsweise auf Erreichbarkeit einzelner Kontrollflusszweige und Verklemmungsfreiheit untersucht werden können.

Frage: Es gab die Kritik, UML 2.0 sei mit Features überfrachtet. Ist diese Kritik berechtigt?

Antwort: Auf den ersten Blick mag man angesichts von drei neuen Diagrammen (damit hat die UML jetzt derer 13) und erweiterter Mächtigkeit bei den bereits existierenden den Eindruck gewinnen, das im Zuge der Standardisierung widerspruchslos den Bedürfnissen unterschiedlichster Anwendergruppen nachgegeben wurde. Und sicherlich enthält auch die UML 2.0 Modellierungskonstrukte, denen kaum eine breite Anwendung beschieden sein wird. Dafür präsentiert sich die UML 2.0 mit einer sauberen Basis, einem aufgeräumten und von Redundanzen befreiten Metamodell. Dies macht sie -- trotz aller Erweiterungen -- schlanker und vor allem verständlicher. Sicher gilt auch für die UML 2.0, dass das beste Werkzeug wenig nützt, wenn es falsch eingesetzt wird, aber auch die 1.x-Version erforderte für eine Erfolg versprechende Anwendung im Projekt ein gezieltes Tailoring.

Frage: Wird es für Softwaredesigner und Entwickler eventuell schwieriger, sich in der neuen Version von UML zurechtzufinden?
Wo erwarten Sie Umstellungs-Schwierigkeiten?

Antwort: Für den erfahrenen UML-Anwender gibt es sicherlich einen gewissen Umgewöhnungsbedarf: So hat sich die graphische Repräsentation einiger Elemente geändert (ein Zustand sieht aus wie eine frühere Aktivität) und Bezeichnungen geändert (das frühere Aktivitätsdiagramm heißt jetzt Aktivität und eine Aktivität heißt jetzt Aktion). Ob man das „alte“ Kollaborationsdiagramm nun als Kommunikationsdiagramm bezeichnet, ändert wenig an seiner Anwendung, allerdings ist es nicht mehr äquivalent zum Sequenzdiagramm, da letzteres in seiner Mächtigkeit stark erweitert wurde. Beachten sollte der Anwender außerdem, daß die UML 2.0 in weiten Bereichen nicht abwärtskompatibel zu ihren Vorgängerversionen ist.

Frage: Ab wann erwarten Sie Tools, die UML 2 umfassend oder doch zumindest größtenteils abdecken? Wie kann sich der Entwickler bis dahin helfen?

Antwort: Natürlich können auch wir nur über den Zeitplan von Toolherstellern mutmaßen. Zur Zeit ist noch kein Tool auf dem Markt, das die UML 2.0 angemessen unterstützt. Vermutlich werden viele Toolhersteller die Neuerungen nach und nach übernehmen. In Erwartung dessen wurde die UML im neuen Standard in drei unterschiedlich komplexe Erfüllungsebenen und Erfüllungspunkte eingeteilt, welche wiederum Notationselemente auf einer Ebene zu Gruppen zusammenfassen. Dies ermöglicht den Anbietern von Modellierungstools die schrittweise, auf ihre jeweilige Zielgruppe zugeschnittene Umsetzung der neuen UML-Version.

Frage: Was würden Sie Softwaredesignern/Entwicklern raten, die über einen Wechsel von UML 1.x zu 2.0 nachdenken? Ist ein Wechsel zu 2.0 in jedem Fall notwendig?

Antwort: Die Erweiterungen der dynamischen Diagrammtypen wie beispielsweise das Sequenz- oder Aktivitätsdiagramm sind für sich alleine genommen schon ein guter Grund für den Wechsel. Ein Wechsel ist vor allem dann ratsam, wenn ein wesentlicher Aspekt Ihrer Modellierungstätigkeit auf der Beschreibung des Systemverhaltens liegt und Sie diese Diagramme intensiv nutzen. Gleiches gilt für die Modellierung technischer Systeme, insbesondere wenn Sie die Kommunikation von Komponenten oder das Zeitverhalten eines Systems abbilden wollen.
Sinnvoll ist der Umstieg auf UML 2.0 aber auch, wenn die Sie häufig Datenströme oder Workflows modellieren, wie bei der Darstellung von Geschäftsprozessen. Und schließlich eröffnet Ihnen die UML 2.0 auch neue Möglichkeiten bei der Generierung von Code oder Architekturen basierend auf einem MDA-Ansatz, oder bei sich schnell ändernden, architektonischen Umfeldern wie EAI (Enterprise Application Integration).

Frage: Gibt es Möglichkeiten, die UML eigenen Bedürfnissen anzupassen?

Antwort: Es gibt 2 grundsätzliche Mechanismen die UML zu erweitern:

• Metamodellveränderung (sog. heavyweight extension)
• Profile (sog. lightweight extensions)

Letztere ergänzen nur die UML, indem sie das Metamodell der UML unberührt lassen und nur erweitern bzw. gültige Regeln einschränken, es werden aber keine Elemente wie Klassen oder Assoziationen hinzugefügt oder weggenommen. In der UML stehen für diese Anpassungen drei Konstrukte zur Verfügung: Stereotypen, tagged values und in OCL formulierte constraints. Eine konkrete Sammlung dieser Konstrukte bezeichnet man als Profil. Der Begriff bzw. die Idee des Profils hat sich mit der UML 2.0 gegenüber den Vorgängerversionennicht geändert. Allerdings sind Profile inzwischen eigene Metamodell-Elemente der UML, somit können Sie auch Profile modellieren. Profile sind einfach ausgedrückt, nichts anderes als Pakete, deren Elemente in erster Linie Ausprägungen der Anpassungskonstrukte sind.

Frage: Inwieweit werden zukünftig Sequenzdiagramme zur Geschäftsprozessmodellierung an Stelle der Aktivitätsdiagramme eingesetzt werden?
Im Gegensatz zu früheren UML-Versionen ist es ja nun möglich, mittels Sequenzdiagrammen durch die erweiterte Mächtigkeit (Modellierung von Parallelität, Wiederholungen usw.) Abläufe darzustellen.

Antwort: Aktivitätsdiagramme werden in der Geschäftsprozeßmodellierung auch in den nächsten Jahren eine vorherrschende Stellung einnehmen. Insbesondere da viele Umsteiger aus anderen Notationen die prozess- oder flußorientierte Darstellung kennen und sich hier leicht zurecht finden. Zudem wurden grobe Mängel in den UML 1.x Aktivitätsdiagrammen mit der UML 2.0 ausgeräumt (z.B. bietet UML 2.0 verbesserte Konstrukte zur Modellierung des Objektflusses an). Dies macht diese Diagrammart noch attraktiver.

Die Vorteile der Sequenzdiagramme im Vergleich mit den Aktivitätsdiagrammen sind die Möglichkeiten zur präzisen Angabe zeitlicher Abläufe und Ereignisreihenfolgen; besonders im Zusammenhang mit Interaktionen. Deren Bedarf ist für die Geschäftsprozessmodellierung aber eher als gering einzuschätzen. Wenn es auf die reine Darstellung der Kommunikation im Rahmen der Geschäftsprozessmodellierung ankommt, ist ein Kommunikationsdiagramm vorzuziehen.

In zukünftigen UML-Versionen, welche möglicherweise mit einer formalen Grammatik ausgestattet werden werden, dürften die Unterschiede zwischen Aktivitätsdiagrammen und Sequenzdiagrammen vermutlich eher gering sein. Der erste Schritt wurde bereits unternommen, indem die Mechanismenzur Einbindung von Objekten in Aktivitätsdiagramme verbessert wurden. Vielleicht wird es dann möglich sein, auf Knopfdruck zwischen Aktivitätsdiagrammen und Sequenzdiagrammen hin- und herschalten. Es ist auch bezeichnend für die UML 2.0, dass man die Diagramme immer mehr als Sicht (view) auf ein Modell betrachtet. Die Kunst wird in der Zukunft sein, die richtige Sicht (d.h. das richtige Diagramm) auszuwählen.

Frage: Was ist die genaue Semantik einer Aktion, die über mehrere ausgehende Kanten verfügt?
Stimmt es, daß an jeder ausgehenden Kante ein separates Token angeboten wird. Wird daher der Kontrollfluß gemäß der Anzahl der ausgehenden Kanten aufgespalten?

Antwort: Es ist zwar richtig, daß an allen ausgehenden Kanten Tokens angeboten werden, aber hierdurch wird keine nebenläufige Verarbeitung erzeugt. Sobald ein Token von einer Folgeaktion (d.h. von einem Folgeknoten) konsumiert (angenommen) wird, stehen die anderen angebotenen Tokens nicht mehr zur Verfügung. Mit anderen Worten, egal wieviele Tokens am Ausgang einer Aktion zur Verfügung stehen, es verlässt in der Regel nur genau ein Token die Aktion.