Damit Sie sich einen Eindruck von unserem neuen Buch machen können, stellen wir Ihnen hier Kapitel 12 sowie das Inhaltsverzeichnis als Leseprobe zur Verfügung.

Wir wünschen Ihnen viel Spaß beim Lesen.

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

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 angenommene Spezifikation durch die Finalization Task Force überarbeitet und editorielle (hierunter fallen schlichte Tipp- und Kopierfehler), sowie kleinere technische 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 seitens der Werkzeughersteller, die bereits mit der Implementierung der UML 2.0 in ihren Produkten begonnen haben.

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

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 wurden erst relativ spät in die UML integriert und in den 1.x-er Spezifikationsversionen 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.

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

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 wurden die semantische Beschreibung der Elemente präziser gefasst, sowie Redundanzen und Inkonsistenzen beseitigt. Dadurch ist die UML 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 Kollaborationsdiagramm 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.

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

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, dass 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.

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

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, dass die UML 2.0 in weiten Bereichen nicht abwärtskompatibel zu ihren Vorgängerversionen ist.

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

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.

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?

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 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).

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

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ängerversionen nicht 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.

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.

Aktivitätsdiagramme werden in der Geschäftsprozessmodellierung auch in den nächsten Jahren eine vorherrschende Stellung einnehmen. Insbesondere da viele Umsteiger aus anderen Notationen die prozess- oder flussorientierte Darstellung kennen und sich hier leicht zurechtfinden. 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 sein werden, dürften die Unterschiede zwischen Aktivitätsdiagrammen und Sequenzdiagrammen vermutlich eher gering sein. Der erste Schritt wurde bereits unternommen, indem die Mechanismen zur Einbindung von Objekten in Aktivitätsdiagramme verbessert wurden. Vielleicht wird es dann möglich sein, auf Knopfdruck zwischen Aktivitätsdiagrammen und Sequenzdiagrammen hin- und herzuschalten. 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

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

Es ist zwar richtig, dass 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.

Warum wird im Downloaddokument zum Klassendiagrammkapitel zur Darstellung mengenwertiger Beziehungen die veraltende Java-Klasse Vector verwendet?

Geschwindigkeitsmessungen zeigen, dass Operationen auf Vector-Objekten einerseits deutlich (je nach Rechner bis zu 180%) schneller ausgeführt werden als beispielsweise auf Ausprägungen von LinkedList, zum anderen besitzt Vector einen deutlich höheren Bekanntheitsgrad als die erst in Java 1.4 eingeführten Nachfolger.
Konzeptionell unterscheidet sich jedoch die gewählte Implementierung nicht von ihren Nachfolgern, daher kann Vector ohne Mächtigkeitsverlust gegen eine andere Klasse der Collection-API ausgetauscht werden.

Falls ein Synchronisationsknoten mit einer OR join-Spezifikation versehen ist (siehe Buch S. 237 unten), werden dann ankommende Tokens trotzdem verschmolzen?

Leider beantwortet die UML-Spezifikation diesen Sachverhalt nicht hinreichend, da im Standard nur der „Normalfall“ also das Synchronisieren mit der Tokenverschmelzung erläutert ist. In unserem Beispiel aus Abbildung 10.74 sind wir eigentlich von einem XOR ausgegangen, d. h. dass nie gleichzeitig die Stadt mit dem Auto oder dem Zug besucht wird.

Würden jedoch 2 Tokens vorliegen, d. h. 1 Token in der Aktion Zug fahren und 1 Token in Auto fahren, so dürften die beiden Tokens nicht verschmolzen werden. Ansonsten wäre die Äquivalenz zum Verbindungsknoten im rechten Teil der Abbildung nicht gegeben.

Kann man mit Profilen auch Änderungen am Metamodell durchführen?

Nein. Im allerersten Dokument zu Profilen war dies noch vorgesehen. Davon hat man sich mittlerweile aber verabschiedet. Dummerweise sind in den offiziellen Profildokumenten aber immer Metamodelländerungen aufgeführt, diese befinden sich aber in extra Dokumentabschnitten und gehören streng genommen nicht zu dem Profil an sich.

Warum gehören eigentlich Use-Cases zu den Verhaltensdiagrammen? Ein Use-Case-Diagramm stellt doch eher ein Struktur- als ein Verhaltensdiagramm dar.

Im Rahmen der UML 2 wurde der Fokus bei den Use-Case-Diagrammen leicht verschoben. Man sieht nun nicht mehr das Use-Case-Diagramm -- also die Statik -- im Vordergrund, sondern stattdessen den einzelnen Use-Case bzw. seine Beschreibung und die dahinterstehenden Abläufe (obwohl diese nicht mit dem Use-Case-Diagramm ausgedrückt werden, sondern vielmehr durch Aktivitätsdiagramme, Zustandsautomaten und meist durch Text).

Im Metamodell der UML äußerst sich diese Zwitterstellung durch eine Mehrfachvererbung: Ein Use-Case ist dort sowohl ein Classifier (ähnlich wie eine Klasse, also eine statische Schnittstelle) als auch ein Behaviour (ein Verhalten, ähnlich wie eine Aktion). Prinzipiell steht aber die letzte Sichtweise bei den UML-Autoren im Vordergrund und genau deswegen die Verschiebung zu den Verhaltensdiagrammen.

Das Use-Case-Diagramm an sich zeigt aber „nur“ statisch die angebotenen Dienstleistungen. Wobei deutlich herausgestellt wurde, dass ein Use-Case einem beliebigen Classifier zugeordnet werden kann, z.B. auch einer Komponente. Damit modellieren Sie eben das angebotene „Dienstleistungsspektrum“ einer Komponente.