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, die durch Verbindungen zwischen den Schritten übertragen werden:
- Als Datenfluss wird die Übergabe von Werten (Resultate, Messwerte, Objekte, Dokumente etc.) von einem Schritt zum nächsten bezeichnet. Ein Datenfluss läuft über Verbindungen vom Ausgangspin (Pin = "Stecker/Sockel") eines Schritts zum Eingangspin eines anderen.
- Kontrollflüsse sind Informationen zum Endestatus eines Schrittes, die verwendet werden können, um die Aktion eines nächsten Schritts zu starten. Sie laufen über Verbindungen vom Trigger-Ausgang eines Schrittes zum Trigger-Eingang eines anderen.
Beide können die Ausführung eines Folgeschritts auslösen.
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.
Semantik[Bearbeiten]
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]
Ein Petri-Netz (siehe Wikipedia) ist ein Netzwerk, das aus Knoten (Stellen oder auch Plätze genannt, mit möglicher Aktionsbehandlung) und Übergängen besteht. In klassischen Petri-Netzen bewegen sich anonyme Tokens entlang von Verbindungen. Übergänge kontrollieren das Auslösen (Triggern) der folgenden Aktionsschritte abhängig von der Ankunft von Tokens auf der Eingangsseite, und geben Tokens an die Ausgangsseite weiter.
Expecco kombiniert die Übergangs- und Stellenfunktionalität in einem einzelnen Schrittelement um die grafische Representation dichter zu machen (und auch um eine Ähnlichkeit mit UML-2-Aktivitätsdiagrammen und anderen flussbasierten Diagrammen zu bekommen). Semantisch verhalten sie sich jedoch gleich und jedes Diagramm könnte mit separaten Elementen umgeschrieben werden (durch sammeln der Eingaben und Weitergabe eines Tupels mit Tokens an die Stelle).
Ein expecco-Schritt mit mehreren Eingabepins entspricht einem Petri-Netz-Übergang mit mehreren Eingaben gefolgt von einer Petri-Netz-Aktion. Wie bei einem Übergang in einem Petri-Netz kann die Eingangsseite eines Schrittes so konfiguriert werden, dass entweder irgendein Eingabewert oder alle Eingabewerte vorliegen müssen. In expecco wird das als "Aktivierungsbedingung" des Schritts bezeichnet und ist genauer in der Dokumentation zum Schritt beschrieben.
"Höhere Petri-Netze" sind Petri-Netze, die andere Petri-Netze als Stellen enthalten, was in expecco genau den zusammengesetzten Aktionen entspricht.
"Farbige Petri-Netze" sind Petri-Netze, bei denen keine einfachen anonymen Tokens weitergereicht werden, sondern Datenobjekte (oder Referenzen darauf, wie in expecco).
Deshalb sind expecco-Diagramme in Standard-Petri-Netz-Notation "Höhere farbige Petri-Netze".
Relation zu UML Aktivitätsdiagrammen[Bearbeiten]
Zusammengesetzte Aktionen in expecco sind isomorph zu UML-Aktivitätsdiagrammen mit einer bestimmten vordefinierten Sammlung an Stereotypen für Verbindungen, Pins und Aktionsschritte. Diese Stereotypen sind in expecco fest einprogrammiert und definieren die Semantik des Auslösens von Aktionen, der Ausführungsreihenfolge von Datenverbindungen und der optionalen parallelen Ausführung von Schritten. Die grafische Representation ist leicht anders; die leicht umständlichen <<Stereotyp>>-Vermerke werden durch verschiedene Pin-Darstellungen (gefüllt/leer usw.) ersetzt. Außerdem sind alle Verbindungen in expecco Objekt-Verbindungen und alle Pins erhalten und erzeugen Objekte als Werte.
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]
Das Aktivitätsdiagramm, das das Verhalten eines zusammengesetzten Bausteins definiert, kann im Netzwerkeditor – auch "Diagrammeditor" oder "Netzwerkdiagrammeditor" genannt – bearbeitet werden. Dieser Editor zeigt die "Innenansicht" des Bausteins. Die Schnittstelle eines zusammengesetzten Bausteins (d.h. Anzahl und Art der Pins) kann hingegen als "Außenansicht" angesehen werden und wird im Schema Editor gezeigt und definiert.
Siehe auch[Bearbeiten]
Block Element, Schritt, Verbindung, Elementaraktion,
Zurück zur Online Documentation.
