Unterschiede zwischen UML 1.x und UML 2.0
Diese Seite beschreibt einige für RUP relevante Unterschiede zwischen UML 1.x und UML 2.0.
Hauptbeschreibung

Themen

Überblick

Auf dieser Seite werden einige für RUP relevante Unterschiede zwischen UML 1.x und UML 2.0 beschrieben. Es werden jedoch nicht alle Spezifikationen hinsichtlich Infrastruktur und Superstruktur von UML ([UML04]) erläutert, sondern ein Überblick über die relevanten UML-Funktionen geboten. Ausführliche Informationen finden Sie darüber hinaus in [RUM05] und [ERI04].

Beachten Sie, dass sich "UML 1.x" auf UML-Versionen von UML 1.0 bis UML 1.5 bezieht.

Die wichtigsten Änderungen hinsichtlich der Diagramme in UML 2.0 wurden bei den Verhaltensdiagrammen (behavioural diagrams) vorgenommen, insbesondere beim Aktivitätsdiagramm (activity diagram) und der Gruppe der Interaktionsdiagramme (interaction diagram). (Nähere Informationen finden Sie in den Abschnitten Aktivitätsdiagramm, Ablaufdiagramm und Kommunikationsdiagramm.)

Zu den weiteren Neuerungen in UML 2.0 gehören das zusammengesetzte Strukturdiagramm (composite structure diagram) und die strukturierte Klasse (structured class). (Nähere Informationen enthält der Abschnitt Zusammengesetztes Strukturdiagramm.)

Aktivitätsdiagramm

Einführung

Die Modellierung von Aktivitäten wurde in UML 2.0 vollständig neu überarbeitet. Man könnte zwar bei einer oberflächlichen Betrachtung behaupten, dass sich in der Darstellung und im Ergebnis zumindest bei einer nicht formalen Modellierung nicht viel geändert hat. Bei einer formellen Modellierung unter Verwendung von UML 1.5 (und früheren Versionen) jedoch, fällt das Ergebnis bei einem unter UML 1.x erstellten Modells anders aus als bei einem unter UML 2.0 erstellen Modells. Daher muss der Modellierer berücksichtigen, dass ein Aktivitätsmodell aus UML 1.x zwar den Anschein erwecken mag, ohne Änderung in UML 2.0 verwendet werden zu können, sich jedoch in der Ausführung möglicherweise anders verhält. Dies gilt insbesondere bei komplexeren Modellen mit Parallelität. Weitere Informationen finden Sie in [UML04].

In [UML04] wird eine Aktivität (dargestellt in einem Aktivitätsdiagramm) als Spezifizierung von Verhalten als koordinierten Ablauf von untergeordneten Einheiten definiert, deren individuelle Elemente Aktionen sind. Die einzelnen ausführbaren Schritte in einem Aktivitätsdiagramm in UML 1.x wurden nicht formal als Aktivitäten (activities) bzw. Aktivitätszustände (activity states) oder genauer gesagt als Aktionszustände (action states) bezeichnet. Diese Schritte heißen in einer UML-2.0-Aktivität nun Aktionen (actions), und diese Aktionen werden innerhalb der Aktivität nicht weiter unterteilt. Das Konzept des Zustands (state) ist in UML 2.0 nicht mehr vorhanden, da Aktivitäten (activity) nicht mehr über eine Zustandsmaschine abgewickelt werden, wie es in UML 1.x der Fall war. In UML 2.0 setzen sich Aktivitäten aus Knoten (nodes) zusammen. Hierzu gehören Aktionen (actions) und, wie weiter unten beschrieben, Steuerungsknoten (control nodes) und Objektknoten (object nodes).

Ablaufsemantik

Die Semantik für Aktivitäten (activities) ist jetzt an die Semantik von Petri-Netzen angelehnt, d. h. die Abarbeitung erfolgt über einen Token-Fluss (token flow). Die Ausführung eines Knotens (node) bewirkt hierbei die Ausführung eines Knotens anderen über richtungsweisende Verbindungen, so genannte Abläufe (flows). Token mit Objekten oder Kontrollpunkten bewegen sich über diese Verbindungen zwischen den Knoten. Ein Knoten kann mit der Ausführung beginnen, sobald die festgelegten Bedingungen am Eingabe-Token erfüllt sind. Nach Abschluss der Ausführung stellt er Token an seinen Ausgabepunkten bereit, so dass nachgeordnete Knoten mit der Ausführung beginnen können. Die Ablaufstrukturen, die Knoten miteinander verbinden, werden weiter unterteilt in Steuerungs- und Daten- bzw. Objektflüsse. Dabei bewegen sich erwartungsgemäß Steuerungs-Token über Steuerungsflüsse und Objekt- bzw. Daten-Token bewegen sich über Objektflüsse.

In UML 1.x. hingegen sind Knoten (nodes) Zustände (states) oder Pseudozustände (pseudo states) mit Übergängen dazwischen, wodurch die Modellierung von Abläufen eingeschränkt wird.

Modellierung für Parallelität

Die Modellierung in UML 2.0 ermöglicht die Verwendung uneingeschränkter Parallelität. In UML 1.x dagegen führte die Zustandsmaschine (Aktivität) jeweils einen Schritt vollständig aus. Das Leistungsspektrum von UML 2.0 ermöglicht es, dass mehrere Aufrufe einer Aktivität in einem einzigen Ausführungsschritt mit mehreren Token-Strömen, die durch die Knoten und Ablaufkonnektoren (flow connectors) der Aktivität fließen, abgewickelt werden. Der Modellierer muss sich daher über die Konkurrenzsituationen und Interaktionen im Klaren sein. Ein weiteres Beispiel für die Auswirkungen von Modellierung für Parallelität auf die Semantik von Token-Flüssen finden Sie im Abschnitt Semantische Unterschiede.

Notation

Aktions- und Steuerungsknoten

Das nachstehende Diagramm veranschaulicht viele der Elemente in UML 2.0. Die Darstellungsweise ist typisch für UML 2.0: ein rechteckiger Rahmen und ein Name in einem Feld im oberen linken Bereich. Vergleichen Sie dieses Diagramm mit dem Diagramm der Version von UML 1.x darunter. Die Diagramme sind sich sehr ähnlich (Abweichungen in der Ausrichtung sowie Farbabweichungen haben keine semantische Bedeutung), und dieses Modell hat sowohl in UML 1.x als auch in UML 2.0 dasselbe Ausführungsergebnis. Beachten Sie, dass sich die Steuerungsknoten - Verzweigungsknoten (decision), Verbindungsknoten (merge), Synchronisationsknoten (join), Startknoten (initial) und Endknoten (final) - optisch nicht von ihren Entsprechungen in UML 1.x unterscheiden. Ein Steuerungsablauf wird mit einer Linie mit Pfeilspitze dargestellt, eine optische Analogie zum Übergangspfeil in UML 1.x.

Abbildung eines Aktivitätsdiagramms mit verschiedenen Knotentypen: Start-, Aktions-, Verzweigungs-, Parallelisierungs-, Synchronisations-, Verbindungsknoten und Endknoten für Aktivität. Der Steuerungablauf wird ebenfalls angezeigt.

Beispiel eines Aktivitätsdiagramms in UML 2.0

Dieses Diagramm entspricht demselben Diagramm für UML Version 1.x.

Beispiel eines Aktivitätsdiagramms in UML 1.x

UML 2.0 stellt einen weiteren Steuerungsknoten bereit, den so genannten Endknoten des Ablaufs (flow final node) (siehe nachfolgend abgebildetes Diagramm aus [UML04]), der alternativ zum Endknoten (activity final node) zum Beenden eines Ablaufs verwendet wird. Dieser Knoten wird benötigt, da in UML 2.0 die gesamte Aktivität (einschließlich aller Abläufe) beendet wird, sobald ein Endknoten erreicht wird. Der Endknoten des Ablaufs beendet lediglich den ihm zugeordneten Ablauf. In UML 1.5 war das kein Problem, da aufgrund der Semantik jeweils ein Schritt vollständig ausgeführt wurde. Sobald uneingeschränkte Parallelität, wie sie in UML 2.0 möglich ist, ins Spiel kommt, ist es nicht wünschenswert, dass alle Abläufe gestoppt und die Token gelöscht werden.

Dieses Diagramm zeigt einen Endknoten des Ablaufs.

Endknoten des Ablaufs

Objektknoten

Die Modellierung von Aktivitäten in UML 2.0 unterstützt auch Objektknoten. Ein Objektknoten ist ein Aktivitätsknoten (activity node), der angibt, dass eine Instanz eines bestimmten Klassifikationsmerkmals, möglicherweise ein bestimmter Zustand, an einem bestimmten Punkt im Aktivitätsablauf, z. B. als Austritt/Eintritt einer Aktion) verfügbar sein wird. Objektknoten sind Container, durch die Objekte eines bestimmten Typs (und möglicherweise bestimmten Zustands) fließen können. In UML 2.0 wurde für Objektknoten eine neue Notation eingeführt: ein Pin. Pins stellen Eingaben für eine Aktion bzw. Ausgaben aus einer Aktion dar und werden als kleine Rechtecke dargestellt, die an die Aktionsrechtecke, wie nachstehend abgebildet, angehängt werden.

Dieses Diagramm zeigt die Notation für Pins bei Objektknoten, mit einem Ausgabepin, der über einen Objektfluss mit einem Eingabepin verbunden ist.

Notation für Pins

Die Pfeile stellen Objektflüsse dar. Es handelt sich um durchgezogene Linien, anders als die gestrichelten Linien, die für Übergänge in und aus Objektflusszuständen in UML 1.x verwendet werden. Wenn der Ausgabepin an einer Aktion denselben Namen wie der Eingabepin der verbundenen Aktion hat, können Ausgabe- und Eingabepins zu einem eigenständigen Pin zusammengeführt werden. Das ist wiederum eine optische Analogie zum Objektfluss in UML 1.x.

Dieses Diagramm zeigt die alternative Notation eines eigenständigen Pins.

Notation für eigenständigen Pin

Strukturierte Aktivitätsknoten

Ein strukturierter Aktivitätsknoten ist ein ausführbarer Aktivitätsknoten, der in weitere untergeordnete Aktivitätsknoten aufgeteilt sein kann. Die untergeordneten Knoten gehören nur zu einem strukturierten Aktivitätsknoten, sie können jedoch verschachtelt angeordnet sein. Mit ihm können Steuerungsflüsse verbunden und es können Pins an ihm angebracht sein. Ein strukturierter Aktivitätsknoten wird als Rechteck mit abgerundeten Ecken mit einer gestrichelten Linie dargestellt, das die Knoten und Flüsse einschließt. Es wird im oberen Bereich mit dem Schlüsselwort <<strukturiert>> gekennzeichnet.

Aktivitätspartitionen

Mit einer Aktivitätspartition (activity partition) können Knoten und Abläufe einer Aktivität nach Zuständigkeiten gruppiert werden. In UML 1.x wurden Verantwortlichkeitsbereiche (swimlanes) (die als Partitionen betrachtet wurden) in Aktivitätsdiagrammen dazu verwendet, Aktionen über ein gemeinsames Kriterium zu gruppieren, z. B. über die Organisationsstruktur in der Geschäftsmodellierung. In UML 2.0 wird diese Partitionierbarkeit bei Aktivitätsdiagrammen auf mehrere Bereiche erweitert und zusätzliche Notation bereitgestellt, so dass beispielsweise einzelne Aktionen mit dem Namen der Partition, zu der sie gehören, versehen werden können. Das nachstehend abgebildete Diagramm ist ein Beispiel für mehrdimensionale Verantwortlichkeitsbereiche, wie sie in UML 2.0 angezeigt werden könnten. Die Aktionen sind nach Standort und Verantwortlichkeit aufgeteilt.

Abbildung einer Aktivitätspartition in UML 2.0 mit zweidimensionalen Verantwortlichkeitsbereichen.

Beispiel einer Aktivitätspartition mit zweidimensionalen Verantwortlichkeitsbereichen

Semantische Unterschiede

Die Semantik für den Token-Fluss und die uneingeschränkte Parallelität bei Aktivitätsmodellen in UML 2.0 setzen voraus, dass der Modellierer, der mit UML 1.x vertraut ist, umsichtig bei der Gestaltung neuer Modelle bzw. der Änderung vorhandener Modelle vorgeht, um sicherzustellen, dass das gewünschte Ausführungsergebnis erzielt wird. In dem oben genannten Beispiel "Passagier abwickeln" kann es sich bei dem Passagier um ein Mitglied im Vielfliegerprogramm handeln. In diesem Fall muss der Servicemitarbeiter dem Passagier, wie in nachstehendem Modellfragment aus UML 1.x dargestellt, Flugmeilen gutschreiben.

Dieses Diagramm zeigt ein Modellfragment aus UML 1.x mit einem überwachten parallelen Übergang.

Verwendung von überwachten parallelen Übergängen

Die Platzierung einer Wächterbedingung an einem optionalen parallelen Übergang bedeutet in UML 1.x, dass der Übergang nie stattfindet. Das Verhalten ist so, als wäre der Übergang nicht im Modell dargestellt. Dementsprechend wird die Ausführung nach der Synchronisation (join) fortgesetzt, nachdem die anderen beiden Übergänge beendet wurden. Wenn ein Passagier in einem UML-2.0-Modell kein Mitglied im Vielfliegerprogramm ist, wird kein Token jemals den Synchronisationsknoten (join) an diesem Fluss erreichen, und das Modell ist wirkungslos, da der Synchronisationsknoten an allen Kanten auf Token wartet, um fortzufahren. Das Modell sollte wie nachstehend abgebildet gestaltet werden, so dass die Bedingung auf dieselbe Weise gehandhabt wird, wie der Gepäckabwicklungsablauf. Es ist zulässig, Wächter direkt in parallele Abläufe zu platzieren, solange gewährleistet ist, dass keine Abhängigkeit zu nachgeordneten Synchronisationsknoten besteht.

Dieses Diagramm zeigt das vorherige Diagramm in UML 2.0. Es werden Verzweigungs- und Verbindungsknoten anstelle der überwachten parallelen Abläufe verwendet.

Verzweigungs- und Verbindungsknoten anstelle überwachter paralleler Abläufe verwenden

Kommunikationsdiagramm

Das Kollaborationsdiagramm (collaboration diagram) aus UML 1.x heißt in UML 2.0 Kommunikationsdiagramm (communication diagram). Es gibt keine semantischen Unterschiede zu früheren Versionen. Das Kommunikationsdiagramm basiert auf dem ehemaligen Kollaborationsdiagramm und ist nach wie vor ein Typ eines Interaktionsdiagramms.

Notation

Der Schwerpunkt eines Kommunikationsdiagramms liegt in der Interaktion von Lebenslinien. Es wird als Graph angezeigt, dessen Knoten, die als Rechtecke abgebildet werden, Teile einer strukturierten Klasse oder Rollen in einer Kollaboration darstellen. Eine Änderung in der Notation gegenüber früheren Versionen von UML besteht darin, dass das Diagramm jetzt von einem rechteckigen Rahmen mit einem Feld für einen Namen im oberen linken Bereich eingefasst wird.

  • Die Knoten entsprechen Lebenslinien in einer Interaktion.
  • Linien zwischen Teilen stellen Konnektoren dar, die Kommunikationspfade bilden.
  • Multiplizitäten können an Konnektoren angezeigt werden.
  • Nachrichten zwischen Teilen werden mit beschrifteten Pfeilen an den Konnektorlinien entlang dargestellt.
Ein Kommunikationsdiagramm wird für die Modellierung von Interaktionen verwendet, die eine Implementierung einer Operation oder eines Anwendungsfalls darstellen.

Beispiel für ein Kommunikationsdiagramm:

Beispiel eines Kommunikationsdiagramms für ein Bestellsystem.

Beispiel eines Kommunikationsdiagramms für ein Bestellsystem

Komponente

In UML 2.0 wird eine Komponente durch ein Klassensymbol ohne die beiden herausragenden Rechtecke, wie sie in UML 1.4 festgelegt sind, dargestellt. Stattdessen wird der Stereotyp <<Komponente>> (Component) verwendet. Optional kann weiterhin ein Komponentensymbol ähnlich dem in UML 1.4 verwendeten Symbol im oberen rechten Bereich des Klassensymbols verwendet werden.

UML 2.0 definiert eine Komponente als eine strukturierte Klasse, so dass die Kollaboration von Elementen in der internen Struktur (Teile) hinsichtlich des Verhaltens modelliert werden kann. Teile sind über Konnektoren miteinander verbunden. Ports können dazu verwendet werden, den Grad der Verkapselung einer Komponente über ihre bereitgestellten und erforderlichen Interfaces zu erhöhen. Weitere Informationen finden Sie im Artikel Konzept: Komponente und Konzept: Strukturierte Klasse.

In früheren Versionen von UML war ein besonderes Modellierungselement, ein Subsystem, definiert, das als Paket mit Schnittstelle modelliert war. Komponenten wurden hier dazu verwendet, das Modell in der physischen Architektur zu strukturieren. In UML 2.0 werden Komponenten globaler über alle Teile des Modells hinweg verwendet. Daher wird kein besonderes Element mehr für die Modellierung von Subsystemen benötigt. Die einzelnen Bereiche für die Realisierung von Subsystemen und die Spezifikation von Subsystemen in UML 1.x wurden auf separate Stereotypen (<<Realisierung>> (Realization) bzw. <<Spezifikation>> (Specification)) verteilt, die auf Komponenten in UML 2.0 angewendet werden. Ein weiterer neuer Stereotyp für Komponenten ist der Stereotyp <<Subsystem>>, mit dem umfangreiche Komponenten modelliert werden können.

RUP empfiehlt die Verwendung von Komponenten für die Modellierung von Subsystemen. (Weitere Informationen finden Sie im Artikel Richtlinie: Subsysteme entwerfen.)

Zusammengesetztes Strukturdiagramm

In einer Architektur können spezifische Kollaborationen von Elementen vorhanden sein, mit Teilen und Konnektoren, die zum Zeitpunkt des Entwurfs nicht notwendigerweise bekannt sein müssen. Ein typisches Klassendiagramm (sowie andere statische Diagramme) eignet sich nicht für die eindeutige Darstellung von Rollen, Zuständigkeiten, Beziehungen und Regeln, die für solche Element gelten.

In UML 2.0 wurde das zusammengesetzte Strukturdiagramm hinzugefügt, um diese Problematik zu behandeln. Mit diesem Diagramm kann die interne Struktur einer strukturierten Klasse, z. B. eine Komponente oder Klasse, einschließlich der Interaktionspunkte der strukturierten Klasse an anderen Teilen des Systems anschaulich dargestellt werden. Es zeigt die Konfiguration von Teilen, die gemeinsam das der beinhalteten strukturierten Klasse entsprechende Verhalten ausführen.

Zusammengesetzte Strukturdiagramme werden verwendet, um Inhalte der strukturierten Klasse darzustellen. (Ausführliche Informationen und Beispiele zu zusammengesetzten Strukturdiagrammen finden Sie im Abschnitt Konzept: Strukturierte Klasse.)

Ablaufdiagramm

UML 2.0 beinhaltet einige neue Features für Ablaufdiagramme:

  • Fragmente bieten eine übersichtlichere Semantik zur Darstellung des Verhaltens innerhalb eines Ablaufdiagramms. Ein kombiniertes Fragment verkapselt Teile eines Ablaufdiagramms zur Modellierung separater Abläufe, über die angezeigt werden kann, wie Bedingungen zu alternativen Ausführungspfaden führen können.

  • Interaktionsvorkommen ermöglichen die Dekomposition von Interaktionen in wiederverwendbare Blöcke. Es kann hilfreich sein, Teile einer Interaktion für andere Interaktionen wiederzuverwenden.

  • In UML 1.x bestand die Möglichkeit, eine Schleife anzugeben, darin, die Schleifenbedingung in eine Notiz zu schreiben. Diese Notiz wurde der Nachricht oder der Gruppe von Nachrichten angefügt, die ausgeführt werden sollten, solange die Bedingung für die Schleife den Wert "true" hatte. In UML 2.0 gibt es eine besondere Darstellungsform für Schleifen.

  • In Ablaufdiagrammen in UML 2.0 kann dargestellt werden, wie Objekte erstellt oder gelöscht werden.

  • Der Ausführungsfokus zeigt den Steuerungsfokus an, den ein Objekt zu einem bestimmten Zeitpunkt, wenn es eine Nachricht empfängt, ausführt.

Durch die neue Art der Darstellung von Fragmenten, Interaktionsvorkommen und Schleifen können Ablaufdiagramme in zwei Varianten verwendet werden:

  • Instanzform: Sie beschreibt detailliert ein spezifisches Szenario und dokumentiert eine mögliche Interaktion ohne Bedingungen, Verzweigungen und Schleifen. Diese Form wird für die Darstellung eines Anwendungsfallszenarios verwendet. Verschiedene Szenarios desselben Anwendungsfalls werden in verschiedenen Ablaufdiagrammen dargestellt. Mit Modellierungstools, die die Semantik von UML 1.x unterstützen, kann nur diese Art der Darstellung verwendet werden.

  • Generische Form: Sie beschreibt alle möglichen Alternativen in einem Szenario und nutzt die Vorteile der neuen Features von UML 2.0, wie z. B. Bedingungen, Verzweigungen und Schleifen. Diese Form kann ggf. für die Darstellung verschiedener Szenarios desselben Anwendungsfalls in einem eindeutigen Ablaufdiagramm verwendet werden.

Die nachstehende Abbildung zeigt ein Beispiel für ein Ablaufdiagramm mit verschiedenen Szenarios. Das Fragment alt zeigt zwei Alternativen für Nachrichtenabfolgen, je nach dem, ob eine Bedingung erfüllt wurde oder nicht:

Ablaufdiagramm mit Verzweigungen, Schleifen und Bedingungen

Beispiel: Ablaufdiagramm mit Verzweigungen, Schleifen und Bedingungen