CompoundBlock Element

Einführung

Ein zusammengesetzter Aktionsblock beschreibt das Verhalten einer Aktion graphisch als Aktivitätsdiagram. Diese Diagramme sind vergleichbar mit den Datenflußdiagrammen wie in UML2.0 definiert. Sie haben außerdem viele Eigenschaften gemein mit Petrinetzen. Das Diagramm besteht aus Unteraktionen, welche als Schritte bezeichnet werden. Die Ausführung wird durch eine Kombination von Daten- und Kontrollflüssen gesteuert. Als Datenfluss wird die Übergabe von Werten (Resultate, Meßwerte, Objekte, Dokumente etc.) von einem Schritt zum nächsten bezeichnet. Kontrollflüsse sind Informationen zum Endestatus eines Schrittes. Beide können die Ausführung eines Folgeschritts auslösen und werden durch Verbingungen der Ausgangspins (Pin = "Stecker/Sockel") zum Eingangspin der Folgeschritte übertragen.

Diagrammelemente

Als "Diagrammelemente" werden die Bestandteile eines Aktivitätsdiagramms bezeichnet. Sie definieren das Verhalten des Zusammengesetzten Aktionsblocks u werden im Netzwerkeditor bearbeitet.

Einführendes Beispiel eines Aktivitätsdiagramms

Das folgende Beispiel erläutert die Hauptkomponenten eines Aktivitätsdiagramms:

Das Diagramm beschreibt den Test einer e-mail Übertragung. Zuerst erzeugt der Schritt "Create Unique ID" eine sog. UUID und stellt diese an seinem Ausgangspin zur Verfügung. Diese UUID wird später gebraucht, um den korrekten Empfang der e-mail zu verifizieren. Die UUID wird vom Schritt "Send E-Mail [SMTP]" empfangen, welcher eine e-mail mittels dem SMTP Protokoll verschickt, und die UUID als Subject verwendet. Als nächstes sorgt der "Time [Delay]" Schritt für eine Verzögerung von 5 Sekunden (in denen die e-mail übermittelt wird). Am Ende prüft der Schritt "Check for incoming Mail" ob eine e-mail mit dem angegebenen Subject angekommen ist, wozu obige UUID gebraucht wird. Der Test wird einen Fehler melden, falls eine solche e-mail nicht gefunden wird.

Beachten Sie bitte, daß die graphische Darstellung des Diagramms im Grunde der UML Notation entspricht. Allerdings werden um die Lesbarkeit zu erhöhen, und um wichtige Aspekte der Ausführung hervorzuheben einige Element etws anders bzw. zusätzlich annotiert dargestellt. Insbesondere werden die Stereotypen der Pins durch unterschiedliche Pin-Darstellungen hervorgehoben, anstatt durch textuelle "<<stereotype>>"-labels, wie in UML.

Schritt (7)

Als "Schritt" wird eine Aktion (Aktionsbaustein) bezeichnet, welcher in ein Diagramm plaziert wurde. Diese Aktione kann ihrerseits entweder ein sog. Elementablock sein (wie z.B. "Create Unique ID"), welche ihre Aktion durch eine textuellen Programmcode definiert, oder wieder ein zusammengesetzter Block (wie z.B. "Check Incoming Mail"), welcher durch ein eigenes Aktivitätsdiagramm definiert wurde. Für das Diagrammnetzwerk in welches der Aktionsblock plaziert wurde ist kein Unterschied im Verhalten sichtbar: ein Diagramm, welches einen Aktionsblock beinhaltet (i.e. einen Schritt enthält) sieht kein unterschiedliches Verhalten in Abhängigkeit der effektiven Realisierung seiner Schritte. Tatsächlich gibt es auch keine Unterschiede in der graphischen Darstellung, so daß es auch für den Entwickler eines zusammengesetzten Blocks keinen Unterschied macht (er muß nicht wissen, wie die Internas einer Aktion aufgebaut sind). Alle Schritte werden gleichermaßen durch die Verfügbarkeit von EIngangsdaten gestartet, führen ihre Berabeitung durch, und liefern ihre Resultate an den Ausgangspins. Details zum Verhalten von Schritten sin in einem separaten Document nachzulesen.

Autostart (1)

A step with autostart option will be triggered automatically, whenever the containing activity diagram network is executed. Without the autostart option, steps are only started when input data arrives at the step's input pin(s). Autostart is required for steps which have no input and are not triggered by a control flow connection. In the above diagram, this is the case for the leftmost "Create Unique ID" step.

The diagram editor renders auto started blocks with a special icon at its top-left corner; if you prefer the standard UML notation, you can place a separate START block and connect its trigger pins.

Pin (3, 6, 9)

Pins are used to exchange data and trigger information between steps. These pins can be output pins (3) to send data or input pins (9) to receive data. Other pins are used for special tasks like exception handling - in the above diagram, the vertical exception output of the "Check Incoming Mail" step is connected to the trigger input of the "FAIL" notifying step. Control-flow pins (trigger and status) are vertical pins, whereas data-flow pins are oriented horizontally. Input pins are always located at the top or left, whereas output pins are always found at the right or bottom. Pins are rendered according to their behavior during execution; especially buffered vs. unbuffered behavior are drawn differently (filled vs. unfilled) to highlight this important fact. Pins are described in detail in a separate document.

Connection (4,8)

Connections are used to interconnect steps to pass data or control information from an output pin to one or more input pins. In the UML sense, all connections are object connections.

Data Flow Connection (4)

These connections deliver data from a step's output pin to another step's input pin. In the example, the first step sends the generated UUID to two other steps. Data flow pins are always located at the left and right of a step (horizontal pins).

Control Flow Connection (8)

These connections are used to control the execution order in an activity diagram. In the example the steps on the right are executed sequential. Control flow pins are always located at the top and bottom of a step (vertical pins).

Freeze Value (6)

The data which is read by a pin can be frozen to a static value (constant). In the example the message text, the e-mail address, the waiting time and also the failure message are frozen. A frozen pin should typically be configured to be non-triggering, non-consuming (so called "parameter pin"). For details on triggering and consumation of values, please read input pin behavior.

Environment Freeze Value (5)

The data for a pin can also read from a variable. These can be defined in the environment of the compound block or the testsuite. In the example, the user name and the server are fetched from such variables. A frozen pin should typically be configured to be non-triggering, non-consuming (so called "parameter pin"). For details on triggering and consumation of values, please read input pin behavior.

Annotation (2)

In order to comment a diagram, or to place additional notes for developers and testers, annotations can be used. Annotations can be either text fields or imported graphics (gif, jpg or png images). You can highlight important parts of the diagram by using an empty text annotation with a non-white background color.

Probes (vsn > 2.1)

Probes (not shown in the above diagram) allow for pin-values to be recorded and/or checked for being valid. Probes provide an easy to use and concise mechanism for value checking. Probes are not supported by pre 2.1 expecco versions.

Relation zu Petrinetzen

A Petri Net ->Wikipedia is a network consisting of places (with possible action processing) and transitions. In a classical petri net, anonymous tokens travel along connections and transitions control the firing (triggering) of following action steps depending on the arrival of tokens at their input side, and passing tokens to their output side. Expecco has combined the transition and place functionality into a single step item, in order to make the graphical representation more dense (and also for its similarity with UML-2 activity diagrams and other flow based diagrams). However, semantically, they behave the same, and any diagram could be rewritten by using separate items (collecting inputs and passing a tuple of tokens on to the place).

An expecco step with multiple input pins corresponds to a Petri Net transition with multiple inputs followed by a Petri Net action. Similar to transitions in a Petri Net, the input side of a step can be configured to require either any input or all input values to be present. In expecco, this is called the step's "trigger condition" and described in detail in the step documentation.

"Higher order Petri Nets" are Petri Nets containing other Petri Nets as places, which is exactly what a compound block is in expecco. "Coloured Petri Nets" are Petri Nets where not simple anonymous tokens are passed around, but data objects (or references to them, as in expecco).

Thus, in standard Petri Net notation, expecco's diagrams are therefore "higher ordered colored Petri Nets".

Relation zu UML Aktivitätsdiagrammen

--- to be written

Relation zu Flußdiagrammen

Activity diagrams can be seen as a superset of flow chart diagrams. Flow charts can be translated into an activity diagram in which only control flow connections are used. Vice versa: an activity diagram which uses only control flow connections and uses no parallelism can be translated back into a flow chart diagram.

The if-then-else conditional branches of a traditional flow chart diagram correspond to the 2-way if action blocks of the expecco standard library. Loops are implemented by connecting a trigger output pin to a previous step's trigger input pin.

Editoren

The activity diagram which defines the behavior of a compound block is edited in the network editor, also called "diagram editor" or "network diagram editor". This editor presents the "internal view" of the block. In contrast, the interface of an compound block (e.g. number and type of pins) can be regarded as its "external view" and is presented and defined in the schema editor.

---

Copyright © 2014-2024 eXept Software AG