Verhaltensdiagramm
Aktivitätsdiagramm
Welche Schritte laufen in welcher Reihenfolge ab, auch parallel?
In der Prüfung steht der Ablauf einer Bestellung oder eines Antrags als Fließtext da, mit Bedingungen, wechselnden Zuständigkeiten und Schritten, die gleichzeitig laufen. Das Aktivitätsdiagramm bringt diesen Text in eine Form: Aktionen in der Reihenfolge ihrer Ausführung, Rauten für Entscheidungen, Balken für parallele Zweige und Partitionen für die beteiligten Rollen. Du erkennst diese Aufgabe daran, dass ein Prozess mit Entscheidungen oder Gleichzeitigkeit beschrieben wird und nicht die Struktur eines Systems.
Kontrollknoten im Vergleich.
Raute mit einer eingehenden und mehreren ausgehenden Kanten.
Nach einer Prüfung soll es unterschiedlich weitergehen, aber nur auf einem Weg. Die Raute nimmt eine eingehende Kante und gibt den Fluss an genau einen ausgehenden Zweig weiter. Welcher das ist, legen die Guards fest, also Bedingungen in eckigen Klammern an jeder ausgehenden Kante; [else] fängt alles ab, was keine andere Kante abdeckt. UML 2.5.1 verlangt nicht, dass sich die Guards gegenseitig ausschließen. Erwartet wird es in der Prüfung trotzdem, weil sonst offen bleibt, welcher Zweig gilt.
Raute mit mehreren eingehenden und einer ausgehenden Kante.
Nach einer Entscheidung laufen zwei Zweige getrennt weiter, obwohl danach für beide dasselbe passiert. Die Zusammenführung bringt sie wieder auf eine Kante und benutzt dafür dieselbe Raute wie die Entscheidung, nur mit mehreren Eingängen und einem Ausgang. Sie wartet auf nichts: Jedes ankommende Token läuft sofort weiter. Soll hinter einer Gabelung auf alle Zweige gewartet werden, brauchst du einen Join: Die Zusammenführung synchronisiert nicht und kann die Folgeaktion mehrfach freigeben.
Balken teilen den Fluss auf und warten wieder aufeinander.
Manche Schritte hängen nicht voneinander ab und sollen gleichzeitig laufen. Die Gabelung (Fork) ist ein dicker Balken mit einem Eingang und mehreren Ausgängen; sie vervielfacht das Token, sodass alle Zweige zusammen starten. Die Vereinigung (Join) ist derselbe Balken in der Gegenrichtung und wartet, bis auf jedem eingehenden Zweig ein Token angekommen ist. Deshalb stehen beide fast immer als Paar im Diagramm.
Endknoten beendet alles, Flussende nur den eigenen Zweig.
Sobald ein Ablauf parallele Zweige hat, musst du beim Ende entscheiden, ob der ganze Ablauf gemeint ist oder nur dieser Weg. Der Endknoten, ein Kreis mit gefülltem Punkt, beendet die gesamte Aktivität und stoppt dabei auch die anderen Zweige. Das Flussende, ein Kreis mit Kreuz, vernichtet nur das ankommende Token, alles Übrige läuft weiter. Ein Diagramm darf mehrere Endknoten und mehrere Flussenden enthalten.
Spalten oder Zeilen zeigen, wer eine Aktion ausführt.
Bei Geschäftsprozessen ist oft genauso wichtig, wer einen Schritt ausführt, wie der Schritt selbst. Partitionen (Swimlanes) teilen das Diagramm dafür in Spalten oder Zeilen mit einem Rollennamen im Kopf, und ordnen die Aktionen hier jeweils einer Rolle zu. UML erlaubt auch mehrere Partitionen pro Aktion, etwa für unterschiedliche Dimensionen. Kanten dürfen die Grenzen überschreiten und machen so jede Übergabe zwischen Rollen oder Systemen sichtbar. Ob die Bahnen senkrecht oder waagerecht stehen, ist eine Layoutfrage und keine Notationsregel.
Objektknoten zeigen, welche Daten zwischen Aktionen fließen.
Neben der Reihenfolge willst du manchmal zeigen, welche Daten von einem Schritt zum nächsten wandern. Dafür steht ein Objektknoten zwischen zwei Aktionen, gezeichnet als Rechteck mit eckigen Ecken und dem Namen der Daten darin. Die erste Aktion erzeugt das Objekt, die zweite nimmt es entgegen. Unter dem Typnamen kann der Zustand in eckigen Klammern stehen, hier [offen] unter Rechnung. An den runden Ecken erkennst du Aktionen, an den eckigen Objekte.
Symbole und Notation.
15 Elemente
Startknoten
Gefüllter Kreis
Hier beginnt die Aktivität, sobald sie aufgerufen wird. Der Startknoten erzeugt das Token, also den Marker, der danach durch das Diagramm wandert. UML erlaubt mehrere Startknoten, in Prüfungsaufgaben ist es fast immer genau einer.
Aktion
Rechteck mit runden Ecken
Ein einzelner Arbeitsschritt, der ausgeführt wird und dann endet. Der Name ist eine Tätigkeit mit Verb, also "Rechnung erstellen" und nicht "Rechnung". Erst wenn die Aktion fertig ist, gibt sie den Fluss weiter.
Kontrollfluss
Pfeil mit offener Spitze
Der Pfeil legt die Reihenfolge fest. Ist die Aktion an seinem Anfang fertig, wandert das Token zur nächsten. Er transportiert keine Daten, nur die Information, dass es weitergeht.
Entscheidung
Raute, ein Eingang, mehrere Ausgänge mit [Guards]
Der Ablauf verzweigt sich, aber genau ein Zweig wird genommen. Welcher, sagen die Guards an den ausgehenden Kanten. In der Prüfung wird erwartet, dass sie sich ausschließen und alle Fälle abdecken.
Zusammenführung
Raute, mehrere Eingänge, ein Ausgang
Führt Zweige einer Entscheidung wieder auf eine Kante zusammen. Sie wartet dabei auf nichts: Jedes ankommende Token läuft sofort weiter. Die Form ist dieselbe Raute wie bei der Entscheidung, nur mit mehreren Eingängen.
Guard
[Bedingung] an der Kante
Eine Bedingung an einer Kante, geschrieben in eckigen Klammern. Der Fluss darf die Kante nur nehmen, wenn die Bedingung wahr ist. [else] steht für alle Fälle, die keine andere Kante abdeckt.
Gabelung (Fork)
Balken, ein Eingang, mehrere Ausgänge
Ein Balken mit einem Eingang und mehreren Ausgängen. Er teilt den Fluss auf, sodass alle ausgehenden Zweige gleichzeitig starten. Die Zweige laufen danach unabhängig voneinander weiter.
Vereinigung (Join)
Balken, mehrere Eingänge, ein Ausgang
Derselbe Balken in der Gegenrichtung: mehrere Eingänge, ein Ausgang. Ohne abweichende Join-Bedingung wartet er, bis auf jedem eingehenden Zweig ein Token angekommen ist, und lässt dann einen Fluss weiterlaufen. So werden parallele Zweige wieder synchronisiert.
Endknoten
Kreis mit gefülltem Punkt
Beendet die gesamte Aktivität, auch noch laufende parallele Zweige. Ein Diagramm darf mehrere Endknoten enthalten; der erste erreichte stoppt den Ablauf.
Flussende
Kreis mit Kreuz
Beendet nur den Zweig, in dem es steht. Das ankommende Token verschwindet, alle anderen Zweige laufen weiter. Typisch am Ende eines Nebenzweigs, der die Hauptarbeit nicht stoppen soll.
Partition
Spalte oder Zeile mit Rollenname (Swimlane)
Eine Spalte oder Zeile mit einem Rollennamen im Kopf. Jede Aktion darin wird von dieser Rolle oder diesem System ausgeführt. Kanten über die Grenze hinweg zeigen die Übergaben.
Objektknoten
Rechteck mit Typname und darunter [Zustand]
Ein Rechteck mit eckigen Ecken für Daten, die zwischen zwei Aktionen fließen. Der Text nennt den Typ oder name:Typ. Darunter kann der Zustand in eckigen Klammern stehen. Die Aktion davor erzeugt das Objekt, die Aktion danach nimmt es entgegen.
Signal senden
Fünfeck mit Spitze nach außen
Schickt ein Signal an einen anderen Ablauf oder ein anderes System. Der eigene Fluss wartet nicht auf eine Antwort, sondern läuft sofort weiter.
Signal empfangen
Fünfeck mit Kerbe
Hält den Fluss an, bis das genannte Signal eintrifft. Danach geht es auf der ausgehenden Kante weiter. Ohne eingehende Kante wartet dieser Knoten bereits ab dem Start der umgebenden Aktivität auf Ereignisse.
Zeitereignis
Sanduhr
Löst den Fluss zu einem Zeitpunkt oder nach einer Frist aus. Die Beschriftung nennt die Bedingung, zum Beispiel "nach 14 Tagen". Der Fluss steht so lange still, bis die Zeit erreicht ist.
So liest und zeichnest du ein Aktivitätsdiagramm.
Wozu das Diagramm da ist
In der Prüfung bekommst du einen Prozess als Fließtext: Der Kunde bestellt, der Shop prüft die Verfügbarkeit, bei einer Absage endet der Vorgang, sonst werden Rechnung und Ware gleichzeitig bearbeitet. Aus so einem Absatz lässt sich schwer ablesen, was in welcher Reihenfolge passiert und was nebeneinander läuft. Das Aktivitätsdiagramm zeichnet genau das: die Schritte eines Ablaufs, die Bedingungen dazwischen, die Stellen mit Parallelität und die Rollen, die dafür zuständig sind.
Dahinter steht eine einfache Vorstellung. UML denkt sich einen Marker, das Token, das beim Startknoten losläuft und an jeder Kante weiterwandert; wo dieses Token gerade steht, entscheidet, was als Nächstes ausgeführt wird. Mit dieser einen Idee erklären sich fast alle Symbole: Eine Raute schickt das Token auf einen Weg, ein Balken vervielfacht es oder wartet darauf, ein Flussende vernichtet nur dieses eine Token und ein Endknoten alle.
Woher die Notation kommt
UML wird von der Object Management Group (OMG) standardisiert, einem Industriekonsortium, das die Spezifikation pflegt. Die aktuelle Fassung ist UML 2.5.1; Aktivitäten stehen dort in Kapitel 15. Die Spezifikation legt fest, welches Symbol wie aussieht und was es bedeutet. Sie schreibt nicht vor, wie du das Diagramm anordnest, welche Farben du nimmst oder mit welchem Werkzeug du zeichnest.
Deshalb lohnt es sich, drei Ebenen zu trennen. Dass ein Guard in eckigen Klammern steht, ist Notation aus der Spezifikation. Dass sich die Guards einer Raute gegenseitig ausschließen und alle Fälle abdecken, ist eine Empfehlung und die Erwartung in der Prüfung, keine Regel der Spezifikation. Dass Partitionen als senkrechte Spalten gezeichnet werden, ist reine Gewohnheit.
So liest du es
Du liest von oben nach unten oder von links nach rechts, immer entlang der Pfeile, und beginnst beim gefüllten Kreis. Die abgerundeten Rechtecke sind Aktionen und tragen eine Tätigkeit mit Verb, die eckigen Rechtecke sind Objektknoten und tragen einen Datennamen. An einer Raute schaust du auf die Beschriftungen in eckigen Klammern, denn diese Guards sagen, unter welcher Bedingung du welchem Zweig folgst.
An einem Balken teilt sich der Ablauf oder wartet er. Von einer Gabelung aus verfolgst du beide Zweige einzeln und liest sie als gleichzeitig; am anschließenden Balken, der Vereinigung, geht es erst weiter, wenn du auf jedem eingehenden Zweig angekommen bist. Gibt es Partitionen, sagt dir die Bahn, in der eine Aktion liegt, wer sie ausführt, und jede Kante über eine Bahngrenze ist eine Übergabe.
Häufige Verwechslung: Ein Flussdiagramm, auch Programmablaufplan genannt, zeigt denselben Gedanken nur für einen einzelnen Ablauf und kennt weder Parallelität noch Zuständigkeiten, während das Aktivitätsdiagramm mit Gabelung, Vereinigung und Partitionen genau dafür Symbole hat. Ein Zustandsdiagramm beantwortet dagegen eine andere Frage: Dort stehen die Kästchen für Zustände, in denen ein einzelnes Objekt verweilt und auf Ereignisse wartet, hier stehen sie für Schritte, die ausgeführt werden und danach den Fluss weitergeben.
So zeichnest du es in der Prüfung
- 1Unterstreiche im Aufgabentext alle Tätigkeiten. Jede wird eine Aktion und bekommt einen Namen mit Verb, also "Bestellung prüfen" und nicht "Prüfung".
- 2Klär, ob nach Zuständigkeiten gefragt ist. Wenn ja, zeichne zuerst die Partitionen als Spalten mit Rollennamen, damit du die Aktionen gleich richtig einsortierst.
- 3Setz den Startknoten und häng den Hauptweg als Kette von Aktionen daran, ohne Verzweigungen. Erst der Normalfall, Sonderfälle kommen später.
- 4Bau die Entscheidungen ein: eine Raute pro Bedingung, an jede ausgehende Kante ein Guard in eckigen Klammern, [else] für den Rest. Führ die Zweige mit einer zweiten Raute wieder zusammen, wenn es danach gemeinsam weitergeht.
- 5Such die Schritte, die nicht aufeinander warten müssen. Öffne sie mit einer Gabelung (Fork) und schließ sie mit einer Vereinigung (Join), sobald der Ablauf wieder auf alle warten soll.
- 6Ergänz die Enden. Der Endknoten schließt den Ablauf ab, das Flussende beendet nur einen Nebenzweig. Trägt die Aufgabe Daten mit, setz Objektknoten zwischen die passenden Aktionen.
- 7Geh das Diagramm zum Schluss einmal mit dem Finger ab, so wie das Token laufen würde. Prüf dabei, ob jeder Zweig irgendwo endet und ob die ausgehenden Kanten jeder Entscheidung passende Guards tragen. Eine Zusammenführung braucht diese Auswahlbedingungen nicht.
Prüfe dich selbst: Eine Reparaturannahme nimmt ein Gerät entgegen. Danach werden Kostenvoranschlag und Ersatzteilprüfung gleichzeitig erledigt, und erst wenn beides vorliegt, ruft die Werkstatt den Kunden an. Zeichnest du zwischen Annahme und Anruf zwei Rauten oder einen Fork und einen Join? Und was passiert mit dem Anruf, wenn du dort versehentlich eine Zusammenführung statt einer Vereinigung setzt?
Typische Prüfungsfehler.
6 Paare
Guards fehlen an der Entscheidung.
Wer den Ablauf im Kopf hat, weiß, welcher Zweig wann gilt, und schreibt es deshalb nicht dazu. Im Diagramm steht dann aber nur, dass es zwei Wege gibt, nicht wann welcher genommen wird. Schreib an jede ausgehende Kante der Raute eine Bedingung in eckigen Klammern; [else] fängt den Rest ab.
Entscheidung als Gabelung gezeichnet.
Balken und Raute sehen beide so aus, als würde der Ablauf hier auseinandergehen, und werden deshalb leicht verwechselt. Der Balken ist aber eine Gabelung: Beide Zweige laufen gleichzeitig, die Bestellung würde also freigegeben und abgelehnt. Freigeben und Ablehnen schließen sich aus, dort gehört eine Raute mit Guards hin.
Parallele Zweige ohne Join zusammengeführt.
Nach einer Gabelung sollen die Zweige wieder zusammen, und die Raute sieht genau danach aus. Sie wartet aber nicht, sondern lässt jedes ankommende Token sofort durch, also wird die Folgeaktion zweimal ausgeführt. Der Balken der Vereinigung (Join) wartet auf beide Zweige und lässt danach genau einen Fluss weiterlaufen.
Aktionen als Substantive benannt.
Aus der Aufgabenstellung übernimmt man die Begriffe oft so, wie sie dort stehen, und das sind meist Substantive. Eine Aktion ist aber ein Schritt, der etwas tut, deshalb gehört ein Verb in den Namen. "Rechnung" ist ein Datenobjekt, "Rechnung erstellen" ist eine Aktion. Das ist eine Empfehlung für verständliche Namen, keine UML-Syntaxregel: Auch eine Aktion darf formal einen substantivischen Namen tragen.
Endknoten statt Flussende im parallelen Zweig.
Ein Zweig ist zu Ende, also setzt man das Symbol hin, das man als Ende kennt. Der Endknoten beendet aber die ganze Aktivität und stoppt dabei den parallelen Zweig, der noch arbeitet. Soll nur dieser eine Weg enden, gehört dorthin das Flussende, der Kreis mit Kreuz.
Unbedingte Ausgänge statt einer Auswahl.
Zwei unbedingte Kontrollflüsse aus einer Aktion geben nach ihrem Ende beide Zweige frei. Im linken Beispiel werden also Freigeben und Ablehnen angeboten, obwohl nur eines passieren soll. Für diese Auswahl zeigt die Raute mit [ok] und [else] die Absicht deutlich. Guards sind auch an anderen Aktivitätskanten erlaubt und werden dort ebenfalls ausgewertet; mehrere Ausgänge sind deshalb nicht grundsätzlich ein UML-Fehler.
Zwei vollständige Beispiele.
Bestellung mit Partitionen: drei Rollen, Entscheidung, Gabelung und Objektfluss.
Kunde, Shop und Lager haben eigene Bahnen, und jede Aktion liegt in der Bahn der Rolle, die sie ausführt. Die Raute hinter der Prüfung trennt den Abbruch vom weiteren Ablauf, danach teilt die Gabelung (Fork) den Fluss in Rechnung und Kommissionierung. Die Rechnung wandert als Objektknoten zum Kunden, und die Vereinigung (Join) lässt erst weiterlaufen, wenn Zahlung und Paket beide da sind.
Mahnlauf: Sendesignal, Empfangssignal, Zeitereignis und Schleife.
Der Zähler startet bei 0. Nach dem Senden der Rechnung wartet ein Zweig auf die vollständige Zahlung, während der andere alle 14 Tage die Frist prüft. Jede Mahnung erhöht den Zähler; der Merge führt zur nächsten Wartezeit. Die gestrichelt umrandete Region umfasst die gesamte Überwachung. Verlässt ein Token sie über eine Blitzkante, werden ihre anderen laufenden Aktionen und Wartevorgänge beendet. So wird eine angenommene Zahlung außerhalb der Region verbucht, ohne dass die Fristüberwachung weiterläuft. Nach drei Mahnungen und einer weiteren Frist wird stattdessen die Überwachung beendet und der Fall ans Inkasso übergeben. Bei gleichzeitig möglichen Ausgängen legt dieses abstrakte Modell keine Priorität fest. Bereits versandte Mahnungen werden durch die Unterbrechung nicht zurückgenommen.