CompoundBlock Element
Inhaltsverzeichnis
Einführung[Bearbeiten]
Ein zusammengesetzter Aktionsblock (englisch "Compound Action") beschreibt das Verhalten einer Aktion graphisch als Aktivitätsdiagramm. Diese Diagramme sind vergleichbar mit den Datenflussdiagrammen 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, Messwerte, 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 Verbindungen der Ausgangspins (Pin = "Stecker/Sockel") zum Eingangspin der Folgeschritte übertragen.
Diagrammelemente[Bearbeiten]
Als "Diagrammelemente" werden die Bestandteile eines Aktivitätsdiagramms bezeichnet. Sie definieren das Verhalten des Zusammengesetzten Aktionsblocks und werden im Netzwerkeditor bearbeitet.
Einführendes Beispiel eines Aktivitätsdiagramms[Bearbeiten]
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, dass 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 etwas 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)[Bearbeiten]
Als "Schritt" wird eine Aktion (Aktionsbaustein) bezeichnet, welcher in ein Diagramm platziert wurde. Diese Aktion 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 platziert wurde ist kein Unterschied im Verhalten sichtbar: ein Diagramm, welches einen Aktionsblock beinhaltet (d.h. 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 dass es auch für den Entwickler eines zusammengesetzten Blocks keinen Unterschied macht (er muss nicht wissen, wie die Interna einer Aktion aufgebaut sind). Alle Schritte werden gleichermaßen durch die Verfügbarkeit von Eingangsdaten gestartet, führen ihre Bearbeitung durch, und liefern ihre Resultate an den Ausgangspins. Details zum Verhalten von Schritten sind in einem separaten Document nachzulesen.
Autostart (1)[Bearbeiten]
Ein Schritt mit der Autostart Option wird automatisch gestartet, sobald das umgebende Netzwerk ausgeführt wird. Schritte ohne Autostart-Option werden lediglich ausgeführt, sobald Daten an den Eingangspins des Schrittes erscheinen. Autostart wird insbesondere für Schritte benötigt, welche keine Eingangspins haben, oder welche nicht durch einen Kontrollfluss gestartet werden. Auch Schritte, deren Eingang lediglich konstante Parameter darstellen müssen so gestartet werden. Im obigen Diagramm trifft dies für den linken "Create Unique ID" Schritt zu.
Im Diagrammeditor werden Schritte mit Autostart mit einem speziellen Icon am linken oberen Rand dargestellt; falls Sie die Standard-UML-Notation bevorzugen, können Sie auch einen START-Block aus der Bibliothek verwenden und dessen Trigger-Ausgangspin mit dem zuerst auszuführenden Schritt verbinden.
Pin (3, 6, 9)[Bearbeiten]
Pins dienen zur Weitergabe von Daten und Triggerinformationen zwischen Schritten. Diese Pins können entweder Ausgangespins (3) sein, um Daten zu senden, oder Eingangspins (9), um Daten zu empfangen. Weitere Pins dienen dazu besondere Situationen wie z.B. Ausnahmebehandlung zu melden. Im obigen Diagramm, ist der Exception-Ausgang des "Check Incoming Mail" Schritts mit dem Trigger-Eingang des "FAIL" Schrittes verbunden. Kontrollflusspins (Trigger und Status) sind vertikal angeordnet, wohingegen Datenflüsse als horizontal Pins dargestellt werden. Eingangspins sind immer oben oder links, Ausgangspins immer unten oder rechts angeordnet. Pins werden entsprechend ihrem Verhalten leicht unterschiedlich dargestellt; insbesondere auf das Puffer- und Triggerverhalten wird durch ausgefüllt vs. nicht gefüllt hingewiesen, da diese wichtig sind für die Ausführung. Pins werden in einem separaten Dokument detailliert beschrieben.
Verbindung (4,8)[Bearbeiten]
Verbindungen dienen zum Weiterleiten von Daten oder Kontrollinformationen zu einem oder mehreren Eingangspins (eines oder mehrerer Folgeschritte). Im Sinne von UML sind alle Verbindungen in expecco immer "Objektverbindungen".
Datenflussverbindung (4)[Bearbeiten]
Diese befördern Daten (-Objekte) von einem Ausgangspin zu einem Eingangspins eines Folgeschritts. Im obigen Beispiel sendet der erste Schritt die erzeugte UUID an zwei weitere Schritte. Datenflusspins sind immer links und rechts angeordnet (horizontale Pins).
Kontrollflussverbindung (8)[Bearbeiten]
Diese dienen dazu, die Ausführung unabhängig von Daten (aber abhängig von der Ausführung eines Schrittes) zu kontrollieren. Im Beispiel werden die Schritte rechts im Bild sequentiell ausgeführt, wozu der Triggerausgang eines Schrittes mit dem Triggereingang eines Folgeschrittes verbunden wurde. Kontrollflusspins sind immer oben und unten angeordnet (vertikale Pins).
Freeze Value (Vorbelegungswert) (6)[Bearbeiten]
Eingangswerte eines Pins können mit einem statischen Wert vorbelegt werden (Konstante). Im Beispiel sind der Text der E-Mail, die E-Mail-Adresse, die Wartezeit und auch die Fehlermeldung auf diese Weise "eingefroren". Ein vorbelegter Pin sollte typischerweise als nicht-triggernd und nicht-konsumierend (sogenannter "Parameterpin") konfiguriert werden, wofür es einen besonderen Menüeintrag gibt (außerdem werden beim "Einfrieren" die Pins vom Editor automatisch als solche umdefiniert). Details zum Triggerverhalten und zum Konsumieren von Eingangswerten finden sie im Dokument: "Verhalten von Eingangspins".
Vorbelegung aus Umgebungsvariablen (5)[Bearbeiten]
Eingangswerte eines Pins können ebenfalls aus einer Variable gelesen werden. Diese Variablen werden in einer sogenannten "Variablenumgebung" bereit gestellt, welche im umgebenden zusammengesetzten Bausteinen oder der Testsuite definiert werden. Im obigen Beispiel werden der Name des E-Mail-Kontos sowie der E-Mail-Serverhost aus solchen Variablen gelesen (und entsprechende Einträge in der Variablenumgebung der Testsuite vorausgesetzt). Wie auch reguläre Vorbelegungen sollte der Pin als nicht-triggernd und nicht-konsumierend definiert werden (i.e. "Parameterpin"). Lesen Sie dazu ebenfalls das Kapitel "Verhalten von Eingangspins".
Annotation (2)[Bearbeiten]
Annotationen dienen dazu, Kommentare oder Zusatzinformationen für Entwickler oder Tester im Diagramm mit abzulegen. Möglich sind sowohl textuelle Annotation, als auch importierte Grafiken (Bilder im GIF-, JPEG- oder PNG-Format). Sie können auch dazu genutzt werden, um wichtige Teile des Diagramms farblich hervorzuheben, indem Sie eine leere Textannotation mit einer Hintergrundfarbe unter Teile ihres Diagramms legen.
Messfühler[Bearbeiten]
Messfühler (im obigen Diagramm nicht gezeigt) dienen dazu Pin-Werte aufzuzeichnen und/oder zu validieren. Messfühler bieten einen komfortablen und lesbaren Mechanismus um Werte auf ihre Gültigkeit zu prüfen.
Relation zu IEC1131[Bearbeiten]
Expeccos Aktivitätsdiagramme ähneln stark den Funktionblöcken der IEC1131-3 FBD Sprache (siehe ua. Wikipedia). Sowohl die grafische Darstellung als auch das Ausführungsverhalten sind vergleichbar. Ingenieure mit einem SPS Hintergrund werden keine Probleme haben, Expeccos Aktionsdefinitionen und zusammengesetzte Aktionen zu verstehen.
Relation zu Petrinetzen[Bearbeiten]
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[Bearbeiten]
--- to be written
Relation zu Flussdiagrammen[Bearbeiten]
Aktivitätsdiagramme können als Obermenge von Flussdiagrammen betrachtet werden. Dazu werden die Aktionen lediglich über Kontrollflussverbindungen (Trigger-in/Trigger-out) verbunden (Daten werden hierbei über Variablen ausgetauscht).
Die Wenn-Dann bedingte Verzeigung eines Flussdiagramms entspricht einem 2-Wege-If Aktionsblock (aus der Standardbibliothek). Schleifen werden durch Verbindungen der Trigger-out mit einem Trigger-in eines vorhergehenden Schrittes definiert.
Editoren[Bearbeiten]
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.
