Aktivitätsdiagramm/activity diagram

• stellt die Vernetzung der elementaren Aktionen und deren Verbindungen mit Kontroll- und Datenflüssen dar (WP)
• Semantik basiert auf der Idee der Petri-Netze

Wichtige Begriffe

ActivityPartition

gruppiert Aktivitäten - entspricht Organisationseinheiten (UML2.4.1 Superstructure 12.3.10)

Initial

Activity Final

UML2.4.1 12.3.6: stoppt alle Flows in einer Aktivität

Action

(UML2.4.1 12.3.2) nicht weiter zelegter Schritt in einer Aktivität. - einfach aus Sicht der Aktivität, kann aber z.B. eine komplexe Operation aufrufen, so das die Aktion doch nicht atomar ist.
Eine Aktion hat eingehende und ausgehende Daten und Controllflüsse.
Erst wenn alle eingehenden Eingebabedingungen erfüllt sind, begint die Ausführung.

Accept Event

Aktion, die auf das Auftreten eines Ereignisses mit bestimmten Bedingungen wartet. (UML2.4.1 12.3.1 → 11.3.2)

Send Signal

Control Flow

spezifiziert die Reihenfolge, in der die Aktionen ausgeführt werden (ES)

Control Node

Decision

Merge Node

UML2.4.1 12.3.36: hiet werden mehrere Eingangsflüsse ohne koordination einfach zu einem Ausgangsstrom gemischt.

Fork

Join

Initial

Activity Final

Flow Final

Data Store

UML2.4.1 12.3.21: Erweiterung von Central Buffer. Zusätzlich behält ein Data Store persistent alle eintreffenden Tokens. Neueintreffende Tokens ersetzen die alten. Es erscheint, als ob alle Tokens den Datestore nicht verlassen.

Object Node

UML2.4.1 12.3.48: abstrakter Aktivitätsknoten, der in einem Objektfluß beteiligt ist.

Object Flow

UML2.4.1 12.3.37: Ein Objektfluß ist eine Aktivitätskante (Activity Edge), über die Objekte/Daten übertragen werden.

Central Buffer

UML2.4.1 Kap.12.3.16 : akzeptiert Tokens von upstream-Knoten und liefert sie an die downstream-Knoten. Es gibt mehrere Eingangsflüsse und mehrere Ausgangsflüsse, Sie können nicht direkt mit Aktionen verbunden werden.

Activity Parameter

UML 2.4.1 12.3.9 Eingabe-Parameter der Aktität, hier beginnt ein Objektfluss bzw. Ausgabe-Parameter, wo ein Objektfluß endet.

Input Pin

UML2.4.1 12.3.3 Objektknoten, der eine Eingabparameter einer Aktion darstellt. (WP über Pin)

Output Pin

UML2.4.1 12.3.40: Objektknoten, die Werte an andere Aktionen ausliefern(WP über Pin)

Value Pin

UML2.4.1 12.3.50 → 11.2.51 : liefert einen Wert, der nicht von einem object-flow kommt. Die Aktion muss aber aus anderen Gründen gestartet worden sein.

Expansion Node

UML2.4.1 12.2.36: Objekt node, der den Fluss über die Grenze einer Expansion-Region darstellt. Es fliest eine Collection hinein, die innerhalb der Expansion Region einzeln verarbeitet wird.
Beim Ausgangsflow werden die Objekte zu einer Collection zusammengesetzt.

Expansion Region

UML2.4.1 12.3.27: Eine Expansion Region wird für jedes Element einer Eingangscollection ausgeführt.

Control Flow

UML2.4.1 12.3.19: Kante, die ein Aktivitätsknoten startet, nach dem der vorgehende geendet hat.

Token

Behälter für Objekt, Datum, Position der Kontrolle, der an einem Aktivitätsknoten präsent sein kann (ES)
Wie bei Pertinetzen kann man sich ein Token als bewegbaren Spielstein vorstellen, der über ein Diagramm wandert. Elementar kann man sich ein Token wie ein Befehlszählerregister in einem Hardwareprozessor vorstellen.

im Paket StructuredActivities gibt es herkömliche strukturierte Programierkonstrukte wie Sequenzen, Schleifen, Bedingungen als Erweiterung zu den fundamentalen Aktivitätskonten.

Eignet sich ein Activity-Diagramm zur Codegenerierung ?

Meinungen:

Full Code generation from UML activity Diagramms: Meist ist die präzise graphische Modellierung zu mühsam

From UML-Diagramms to behaviorarl source Code

hat Überlegungen dazu: Bislang ist es nicht üblich

Activity Diagrams : A Formal Framework to Model Business Processes and Code Generation

Es fehle eine formale Semantik für die Codegenerierung
→ Diese gibt es bei fUML und ALF

Abstraktionsebene

Es fragt sich, ob die Modellierung mit einem Aktivitätsdiagramm so nah am Code ist, dass man direkt Code erzeugen will.
Möglicherweise möchte man nur einen groben Überblick verschaffen.
Eventuell könnte man Aktivitätsdiagramme aus Kennzeichen im Code rekonstruieren, um Code und Aktivitätsdiagramm konsistent zu halten.

Codegenerierung ist möglich mit fUML und ALF

• Nach ES ist eine textuelle Actionlanguage auf dem selben Abstraktionsniveau wie das Activity-Diagramm besser geeignet
• Hier ist auf den Unterschied zwischen dem Abstrakten Modell und verscheidenen Repräsentationen zu denken. Verschiedene Repräsentionen können inneinander umgewandelt werden.
• Ein hohes Abstraktionsniveau bietet ein automatisches Optimirungspotential