Themen
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.)
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.
Beispiel eines Aktivitätsdiagramms in UML 2.0
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.
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.
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.
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.
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.
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.
Verzweigungs- und Verbindungsknoten anstelle überwachter paralleler Abläufe verwenden
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
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.)
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.)
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:
Beispiel: Ablaufdiagramm mit Verzweigungen, Schleifen und Bedingungen
|