Übungsaufgaben zum UML-Aktivitätsdiagramm
https://bildung.social/@oerinformatik/117480585690795068
https://oer-informatik.de/uml-aktivitaetsdiagramm-uebungsaufgaben
tl/dr; (ca. 31 min Lesezeit, Bearbeitung deutlich länger): Drei Übungsaufgaben im Stil der IT-Abschlussprüfung zum UML-Aktivitätsdiagramm: einen Ablauf aus einer Beschreibung mit Schwimmbahnen zeichnen, ein angefangenes Diagramm erweitern, Fehler in einem Diagramm finden und korrigieren, Aktionen aus einer ungeordneten Liste in vier Schwimmbahnen anordnen, einen Systemablauf mit Schleife darstellen und Ablaufvarianten begründet bewerten. Alle Lösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 21.10.2026)
Diese Übungsaufgaben gehören zum Artikel UML-Aktivitätsdiagramm. Detailliertere Notationsmöglichkeiten werden in diesem Artikel zu Aktivitätsdiagrammen mit Signalen und Exceptions vorgestellt. Eine weitere Übung mit Beispiellösung findest Du unter Übungsaufgabe WebApp; wie man mit Aktivitätsdiagrammen Geschäftsprozesse analysiert und verbessert, zeigt der Artikel Geschäftsprozesse digitalisieren und optimieren.
Hinweise zur Bearbeitung: Die Aufgaben sind wie Prüfungsaufgaben aufgebaut (FIA Teil 2), aber umfangreicher, damit alle typischen Fragestellungen vorkommen. Zeichne Deine Diagramme auf Papier oder mit einem Werkzeug Deiner Wahl, bevor Du die Musterlösung aufklappst. Bezeichnungen dürfen von der Musterlösung abweichen, solange sie die Tätigkeit beschreiben (Objekt + Verb); andere fachlich richtige Anordnungen sind ebenfalls richtig. In der Prüfung liegt ein Belegsatz mit einer Notationsübersicht bei. Für diese Übungen kannst Du die folgende Übersicht nutzen:
Aufgabe 1: Sessions für das Barcamp einreichen (FIA T2-Niveau)
Du bist Auszubildende*r im Schüler*innen-Team, das für das Barcamp „Lernen.Digital.Leben 2027“ am Ratz und Rübe Berufskolleg die Barcamp-Software entwickelt. Der Call for Participation läuft vom 01.10.2026 bis zum 31.01.2027. Dimitrios Papadopoulos, der die Organisation leitet, hat Dir den geplanten Ablauf für das Einreichen einer Session beschrieben:
Eine Referentin oder ein Referent füllt das Einreichungsformular aus und sendet es ab.
Die Barcamp-Software prüft die Pflichtangaben. Fehlen Angaben, zeigt sie einen Hinweis auf die fehlenden Angaben an. Die Referentin oder der Referent füllt das Formular dann erneut aus und sendet es wieder ab.
Sind alle Pflichtangaben vorhanden, speichert die Software die Einreichung und sendet eine Eingangsbestätigung.
Danach bewertet das Orga-Team die Einreichung. Es gibt drei mögliche Ergebnisse:
Hat das Orga-Team eine Rückfrage, stellt es die Rückfrage. Die Referentin oder der Referent überarbeitet daraufhin die Einreichung, und das Orga-Team bewertet sie erneut. Die Pflichtangaben werden dabei nicht noch einmal geprüft.
Lehnt das Orga-Team die Einreichung ab, sendet die Software eine Absage. Der Vorgang ist damit beendet.
Nimmt das Orga-Team die Einreichung an, laufen zwei Dinge gleichzeitig ab: Die Referentin oder der Referent lädt eine Kurzbeschreibung und ein Foto für den Sessionplan hoch. Das Orga-Team ordnet der Session einen Raum und einen Slot zu. Hat die Referentin oder der Referent in der Einreichung einen Bedarf an Barrierefreiheit angegeben (z. B. Schriftdolmetschung oder einen Raum mit Aufzug), stimmt das Orga-Team diesen Bedarf vorher mit ihr oder ihm ab.
Erst wenn das Hochladen und die Zuordnung von Raum und Slot erledigt sind, veröffentlicht die Software die Session im Sessionplan und sendet der Referentin oder dem Referenten eine Zusage. Damit ist der Vorgang beendet.
Abbruchmöglichkeiten (z. B. eine Einreichung zurückziehen) sollen nicht dargestellt werden.
a) Erstelle für diesen Ablauf ein UML-Aktivitätsdiagramm mit den Schwimmbahnen Referent*in, Orga-Team und Barcamp-Software. Nutze die Notationsübersicht. (24 Punkte)
Punkteverteilung (24 Punkte):
13 Aktionen in der richtigen Schwimmbahn und an der richtigen Stelle, je 1 P (13 P): Einreichungsformular ausfüllen und absenden, Pflichtangaben prüfen, Hinweis auf fehlende Angaben anzeigen, Einreichung speichern und Eingangsbestätigung senden, Einreichung bewerten, Rückfrage stellen, Einreichung überarbeiten, Absage senden, Bedarf mit Referent*in abstimmen, Raum und Slot zuordnen, Kurzbeschreibung und Foto hochladen, Session im Sessionplan veröffentlichen, Zusage senden.
Entscheidungen mit vollständigen, sich ausschließenden Bedingungen in eckigen Klammern (4 P): Pflichtangaben 1 P, Bewertung mit drei Ausgängen 2 P, Barrierefreiheitsbedarf 1 P.
Zusammenführungen (3 P): vor dem Formular (Schleife bei fehlenden Angaben), vor „Einreichung bewerten“ (Schleife bei Rückfrage), nach dem optionalen Abstimmen des Bedarfs.
Teilung nach der Annahme und Synchronisation vor dem Veröffentlichen (2 P).
Startknoten und Endknoten (Absage und regulärer Abschluss) (1 P).
übersichtliche Anordnung, Kontrollfluss durchgehend mit Pfeilen (1 P).
Hinweise zur Bewertung:
Die Entscheidung nach dem Bewerten darf auch als zwei aufeinanderfolgende Entscheidungen modelliert werden (z. B. erst
[angenommen]/[else], dann[abgelehnt]/[Rückfrage]).„Einreichung speichern“ und „Eingangsbestätigung senden“ dürfen getrennte Aktionen sein.
Beide Endknoten dürfen auch über eine Zusammenführung zu einem gemeinsamen Endknoten geführt werden. Ein Ablaufende statt des Endknotens nach der Absage ist ebenfalls richtig, weil zu diesem Zeitpunkt nur ein Token unterwegs ist.
Die Entscheidung „Bedarf angegeben?“ liegt in der Bahn des Orga-Teams, weil das Orga-Team sie trifft.
Typische Fehler: Bedingungen in der Raute statt an den Kanten, fehlende
[else]-Bedingung, Synchronisation fehlt (die Software würde die Session veröffentlichen, bevor Raum und Foto feststehen), Schleife zurück zum Startknoten statt zu einer Zusammenführung.
b) Ein Lehrer aus dem Orga-Team schlägt vor, den Ablauf statt mit einem UML-Aktivitätsdiagramm mit einem Programmablaufplan (PAP nach DIN 66001) darzustellen, weil den alle aus dem Unterricht kennen. Begründe mit zwei Argumenten, warum für diesen Ablauf das Aktivitätsdiagramm besser geeignet ist. (4 Punkte)
Je Argument 2 Punkte, zwei der folgenden (oder andere fachlich richtige):
Verantwortlichkeiten: Am Ablauf sind drei Beteiligte (Referent*in, Orga-Team, Software) beteiligt. Das Aktivitätsdiagramm ordnet jede Aktion über Schwimmbahnen (Partitionen) einer oder einem Verantwortlichen zu; der PAP kennt keine Schwimmbahnen.
Parallelität: Hochladen und Raumzuordnung laufen gleichzeitig. Das Aktivitätsdiagramm kann das mit Teilung und Synchronisation darstellen; im PAP lassen sich nur nacheinander ablaufende Schritte zeigen.
Geschäftsprozess statt Programm: Der PAP ist für Programmabläufe gedacht. Das Aktivitätsdiagramm eignet sich auch für Geschäftsprozesse und ist Teil der UML, die im Projekt ohnehin für Anwendungsfälle und Klassen genutzt wird.
c) In Deinem Diagramm steht vor „Session im Sessionplan veröffentlichen“ eine Synchronisation. Begründe, warum an dieser Stelle keine Zusammenführung (Raute) verwendet werden darf. (3 Punkte)
Nach der Teilung sind zwei Token unterwegs, je einer in jedem parallelen Zweig (1 P). Eine Zusammenführung reicht jeden ankommenden Token sofort weiter. Die Session würde also zweimal veröffentlicht, und zwar das erste Mal schon, wenn nur einer der beiden Zweige fertig ist – z. B. ohne Foto oder ohne Raum (1 P). Die Synchronisation wartet, bis an allen eingehenden Kanten ein Token angekommen ist, und gibt dann genau einen Token weiter. So wird erst veröffentlicht, wenn beides erledigt ist (1 P).
Aufgabe 2: Mitfahrt anfragen und Flurmonitore aktualisieren (FIA T2-Niveau)
Du bist Auszubildende*r im FIA-Projektteam, das für das Ratz und Rübe Berufskolleg die Mitfahr-App „RatzFahrt“ entwickelt. Oksana Melnyk aus Deinem Team hat begonnen, den Anwendungsfall „Mitfahrt anfragen“ als Aktivitätsdiagramm zu beschreiben. Sie ist für zwei Wochen in der Berufsschule und bittet Dich, das Diagramm fertigzustellen. Ihre Notizen:
Die Mitfahrerin oder der Mitfahrer wählt ein Angebot aus und fragt die Mitfahrt an. Die App speichert die Anfrage. (Das ist schon gezeichnet.)
Danach prüft die App, ob in dem Angebot noch ein Platz frei ist. Ist das Angebot inzwischen ausgebucht, zeigt die App die Meldung „ausgebucht“ an, und die Person kann ein anderes Angebot auswählen.
Ist ein Platz frei, prüft die App, ob die Person minderjährig ist. Ist sie minderjährig und liegt keine Einwilligung der Erziehungsberechtigten vor, lehnt die App die Anfrage ab und zeigt einen Hinweis zur Einwilligung an. Damit ist der Vorgang beendet.
Andernfalls benachrichtigt die App die Fahrerin oder den Fahrer. Diese*r prüft die Anfrage und bestätigt sie oder lehnt sie ab.
Bei einer Ablehnung informiert die App die Mitfahrerin oder den Mitfahrer über die Ablehnung. Der Vorgang ist beendet.
Bei einer Bestätigung reduziert die App die Zahl der freien Plätze und sendet gleichzeitig eine Bestätigung mit Treffpunkt und Abfahrtszeit. Sind beide Aktionen erledigt, ist der Vorgang beendet.
a) Erweitere das angefangene Aktivitätsdiagramm so, dass es den beschriebenen Ablauf vollständig darstellt. Ergänze auch in der Vorgabe, was dafür nötig ist. (16 Punkte)
Punkteverteilung (16 Punkte):
7 neue Aktionen in der richtigen Schwimmbahn, je 1 P (7 P): Meldung „ausgebucht“ anzeigen, Anfrage ablehnen und Hinweis anzeigen, Fahrer*in benachrichtigen, Anfrage prüfen (Bahn Fahrer*in), Mitfahrer*in über Ablehnung informieren, freie Plätze reduzieren, Bestätigung mit Treffpunkt senden.
drei Entscheidungen mit Bedingungen in eckigen Klammern, je 1 P (3 P).
Zusammenführung vor „Angebot auswählen“, in die der Rücksprung mündet (1 P). Dazu muss die vorgegebene Kante zwischen Startknoten und „Angebot auswählen“ aufgetrennt werden. Ein Pfeil direkt auf „Angebot auswählen“ wäre nach UML falsch: Eine Aktion mit zwei eingehenden Kanten wartet wie eine Synchronisation auf Token an beiden Kanten.
Teilung und Synchronisation bei der Bestätigung (2 P).
drei Endknoten oder ein gemeinsamer Endknoten mit Zusammenführung (1 P).
„Anfrage prüfen“ und die Entscheidung darüber liegen in der Bahn Fahrer*in, alle Prüfungen und Benachrichtigungen in der Bahn der App (2 P).
Die Prüfung „minderjährig und keine Einwilligung“ darf auch als zwei verschachtelte Entscheidungen (erst Alter, dann Einwilligung) mit anschließender Zusammenführung dargestellt werden.
b) Die Flurmonitore der Schule zeigen offene Angebote und Gesuche anonym an. Bis die geplante automatische Benachrichtigung der Monitore fertig ist, ruft ein Mini-Player am Monitor die Daten der View v_monitor regelmäßig selbst ab. Jonas Wolff hat den Ablauf auf dem Player so modelliert:
Gemeint war: Der Player ruft die Daten ab. Kommen Daten an, bereitet er sie anonym auf, sonst blendet er den Hinweis „offline“ ein. Danach aktualisiert er die Anzeige und passt gleichzeitig die Helligkeit an die Tageszeit an. Ebenfalls gleichzeitig protokolliert er den Abruf; auf das Ende des Protokollierens wird nicht gewartet. Wenn Anzeige und Helligkeit fertig sind, plant er den nächsten Abruf in 60 Sekunden.
ba) Der Player empfängt beim Abruf Daten. Beschreibe mithilfe des Tokenmodells, wie das Diagramm in der vorliegenden Form dann tatsächlich abläuft. (4 Punkte)
Der Startknoten erzeugt einen Token. Er durchläuft „Anzeigedaten über v_monitor abrufen“ und verlässt die Raute über „ja“ zu „Angebote und Gesuche anonym aufbereiten“ (1 P).
Danach erreicht der Token den ersten schwarzen Balken. Das ist eine Synchronisation: Sie gibt erst einen Token weiter, wenn an allen eingehenden Kanten ein Token liegt (1 P).
Über die Kante von „Hinweis „offline“ einblenden“ kommt aber nie ein Token, weil die Entscheidung nur einen der beiden Zweige auswählt. Der Ablauf bleibt an der Synchronisation stehen (Verklemmung, deadlock) (1 P).
Die Anzeige wird also nie aktualisiert, die Helligkeit nie angepasst, und es wird kein neuer Abruf geplant. Der Monitor zeigt dauerhaft den alten Stand, die Aktivität endet nicht (1 P). (Dasselbe passiert, wenn keine Daten empfangen werden.)
bb) Das Diagramm enthält vier Fehler. Beschreibe die vier Fehler und ergänze jeweils, wie sie korrigiert werden. (8 Punkte)
Je Fehler 1 P für die Beschreibung und 1 P für die Korrektur:
| Fehler | Korrektur |
|---|---|
| Die Bedingung steht als Frage in der Raute, die Ausgänge heißen „ja“ und „nein“ (Schreibweise des Programmablaufplans). | Raute leer lassen, Bedingungen in eckigen Klammern an die ausgehenden Kanten schreiben: [Daten empfangen] und [else]. |
| Die beiden Zweige der Entscheidung werden mit einer Synchronisation zusammengeführt. Weil nur ein Zweig einen Token bekommt, wartet die Synchronisation ewig (Verklemmung). | Zusammenführung (Raute) statt Synchronisation verwenden. |
| Die parallelen Zweige „Anzeige aktualisieren“ und „Helligkeit an Tageszeit anpassen“ werden mit einer Raute zusammengeführt. Beide Token laufen weiter, „Nächsten Abruf in 60 s planen“ wird zweimal ausgeführt (doppelte Abrufe). | Synchronisation (Balken) statt Zusammenführung verwenden. |
| Nach „Abruf protokollieren“ steht ein Endknoten. Er beendet die gesamte Aktivität und entfernt alle Token – auch die der anderen Zweige. Ist das Protokollieren zuerst fertig, wird die Anzeige nicht mehr aktualisiert. | Ablaufende (Kreis mit Kreuz) verwenden: Es beendet nur diesen Zweig. |
Korrigiertes Diagramm (zur Kontrolle, war nicht verlangt):
Aufgabe 3: Individualrahmen im Onlineshop (FIA T2-Niveau)
Du bist Auszubildende*r im Entwicklungsteam der CSB-Rad GmbH in Bielefeld. Kund*innen können im Onlineshop einen Fahrradrahmen nach Maß konfigurieren (Rahmenform, Rahmenhöhe, RAL-Farbe). Den Rahmen fertigt die Rahmenwerk OWL GmbH in Gütersloh; Montage, Qualitätsprüfung und Versand übernimmt die Werkstatt in Sennestadt. Werkstattleiter Bastian Ludwig beschreibt Dir den Ablauf:
Die Kundin oder der Kunde konfiguriert den Rahmen und bestellt. Der Onlineshop sendet eine Bestellbestätigung und übermittelt anschließend den Fertigungsauftrag an das Rahmenwerk.
Das Rahmenwerk prüft, ob der Auftrag machbar ist. Ist die gewünschte Pulverfarbe nicht lieferbar, bietet der Onlineshop Alternativfarben an. Die Kundin oder der Kunde wählt eine Alternativfarbe, und der Onlineshop übermittelt den Fertigungsauftrag erneut.
Ist der Auftrag machbar, fertigt das Rahmenwerk den Rahmen und liefert ihn an die Werkstatt. Währenddessen bestellt die Werkstatt bei der Lipper SchließTec KG die gleichschließenden Schlösser – aber nur, wenn welche zur Bestellung gehören.
Sobald der Rahmen geliefert ist und – falls nötig – die Schlösser bestellt sind, montiert die Werkstatt das Rad und prüft die Qualität. Findet sie Mängel, behebt sie die Mängel und prüft erneut.
Ist das Rad ohne Mängel, versendet die Werkstatt das Rad. Gleichzeitig erstellt der Onlineshop die Rechnung. Danach ist der Vorgang abgeschlossen.
Stornierungen und Zahlungsprobleme müssen nicht dargestellt werden. In einem Workshop wurden die folgenden Aktionen gesammelt – noch ohne Reihenfolge:
| Kund*in | Onlineshop | Werkstatt | Rahmenwerk OWL |
|---|---|---|---|
| Alternativfarbe wählen | Rechnung erstellen | Mängel beheben | Rahmen fertigen und liefern |
| Rahmen konfigurieren und bestellen | Fertigungsauftrag übermitteln | Rad versenden | Machbarkeit prüfen |
| Alternativfarben anbieten | Qualität prüfen | ||
| Bestellbestätigung senden | Gleichschließende Schlösser bestellen | ||
| Rad montieren |
Für das Diagramm sind die vier Schwimmbahnen und der Startknoten vorgegeben:
a) Vervollständige das vorgegebene UML-Aktivitätsdiagramm mithilfe der gesammelten Aktionen und der Beschreibung. (24 Punkte)
Punkteverteilung (24 Punkte):
13 Aktionen in der richtigen Schwimmbahn und an der richtigen Stelle, je 1 P (13 P).
Entscheidungen mit Bedingungen: Machbarkeit, Schlösser, Qualität, je 1 P (3 P).
Zusammenführungen: vor „Fertigungsauftrag übermitteln“ (Rücksprung über die Bahnen hinweg), nach der optionalen Schlossbestellung, vor „Qualität prüfen“ (Schleife), je 1 P (3 P).
Teilung und Synchronisation für Rahmenfertigung und Schlossbestellung sowie für Versand und Rechnung, je Paar 2 P (4 P).
Start- und Endknoten (1 P).
Hinweise zur Bewertung:
Die Entscheidung „Schlösser bestellt?“ liegt innerhalb des parallelen Zweigs der Werkstatt. Würde man stattdessen vor der Teilung entscheiden, müsste „Rahmen fertigen und liefern“ zweimal im Diagramm stehen (einmal mit, einmal ohne Schlösser). Beide Varianten sind richtig, wenn alle Zweige korrekt zusammengeführt bzw. synchronisiert werden.
Ohne Zusammenführung nach dem
[else]-Zweig würde ein Zweig der Synchronisation fehlen, wenn keine Schlösser bestellt werden – der Ablauf bliebe stehen.Die Entscheidung über die Machbarkeit trifft das Rahmenwerk, sie gehört in dessen Bahn.
b) Sophie Bertram überlegt, den Ablauf zu ändern. Zwei Varianten stehen zur Wahl:
| Variante 1 | Variante 2 |
|---|---|
| Der Onlineshop übermittelt den Fertigungsauftrag sofort nach der Bestellung. Die Zahlung wird parallel dazu abgewickelt; die Rechnung wird erst beim Versand erstellt (wie oben). | Der Onlineshop übermittelt den Fertigungsauftrag erst, wenn eine Anzahlung von 30 % des Kaufpreises eingegangen ist. Bis dahin wartet die Bestellung. |
Wähle eine Variante aus und begründe Deine Wahl mit zwei Argumenten hinsichtlich der Praxistauglichkeit. (4 Punkte)
Je Argument 2 Punkte. Beide Varianten sind möglich, wenn die Begründung stimmig ist, z. B.:
Variante 2: Ein Rahmen nach Maß in Wunschfarbe lässt sich kaum an andere Kund*innen verkaufen. Zahlt die Kundin oder der Kunde nicht oder storniert, bleibt die CSB-Rad GmbH auf den Fertigungskosten sitzen. Die Anzahlung sichert dieses Risiko ab. Außerdem zeigt die Anzahlung, dass die Bestellung ernst gemeint ist (weniger Spaßbestellungen im Konfigurator).
Variante 1: Die Lieferzeit für Individualrahmen ist mit 6–8 Wochen ohnehin lang; jeder Tag Wartezeit auf eine Zahlung verlängert sie weiter und kann zu Kaufabbrüchen führen. Außerdem kennt der Onlineshop bei Händlern und öffentlichen Auftraggebern, die auf Rechnung kaufen, die Zahlungsmoral aus früheren Bestellungen; eine Anzahlung wäre dort unüblich.
Nicht ausreichend sind Argumente ohne Bezug zum Ablauf („Variante 1 ist besser, weil sie einfacher ist“).
c) Nach jeder Bestellung aktualisiert der Onlineshop automatisch den Lagerbestand. Im Lager liegen z. B. die hydraulischen Scheibenbremsen BRE-HYD-01 bereits unter dem Mindestbestand. Cem Sarıkaya beschreibt den Ablauf so:
Für jede Position der Bestellung verringert das System den Bestand des Artikels um die bestellte Menge. Liegt der Bestand danach unter dem Mindestbestand, prüft das System, ob für den Artikel schon eine offene Nachbestellung existiert. Nur wenn das nicht der Fall ist, legt es eine Nachbestellung an. Sind alle Positionen verarbeitet und wurde dabei mindestens eine Nachbestellung angelegt, sendet das System eine E-Mail an den Einkauf und aktualisiert gleichzeitig das Einkaufs-Dashboard. Danach ist die Aktivität beendet.
Stelle diesen Ablauf als UML-Aktivitätsdiagramm dar. Schwimmbahnen sind nicht erforderlich. (12 Punkte)
Punkteverteilung (12 Punkte):
Start- und Endknoten (1 P).
Schleife über die Positionen: Zusammenführung als Schleifeneinstieg, Entscheidung mit
[weitere Bestellposition]und[alle Positionen verarbeitet], Rücksprung (3 P). Die Prüfung steht vor der ersten Aktion (kopfgesteuert), denn eine Bestellung ohne Positionen soll nichts verändern.vier Aktionen, je 1 P (4 P).
verschachtelte Entscheidungen „Bestand unter Mindestbestand“ und „keine offene Nachbestellung“ mit
[else]-Zweigen und Zusammenführungen (2 P). Eine einzige Entscheidung mit der Bedingung[Bestand < Mindestbestand und keine offene Nachbestellung]ist ebenfalls richtig.Entscheidung
[Nachbestellung angelegt]/[else]mit Teilung und Synchronisation nur im ersten Zweig und Zusammenführung vor dem Endknoten (2 P).
Links und weitere Informationen
Fortgeschrittene Techniken: Objektfluss, Signale, Exceptions
als Primärquelle: die UML-Spezifikation 2.5.1 der Object Management Group, Kapitel 15 (Activities): https://www.omg.org/spec/UML/2.5.1
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zum UML-Aktivitätsdiagramm” von Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-aktivitaetsdiagramm-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/umlaktivitaet. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 21.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
