CompoundBlock Element

Aus expecco Wiki (Version 2.x)
Wechseln zu: Navigation, Suche

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:

Ein Aktivitätsdiagramm

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 sind in einem separaten Document nachzulesen.

Autostart (1)

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 Kontrollfluß 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 Standart-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)

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 horozintal 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)

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)

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)

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 Triggerasugang eines Schrittes mit dem Triggereingang eines Folgeschrittes verbunden wurde. Kontrollflusspins sind immer oben und unten angeordnet (vertikale Pins).

Freeze Value (Vorbelegungswert) (6)

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 (sogenannten "Parameterpin") konfiguriert werden, wofür es einen besonderen Menueintrag gibt (außerdem werdem 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)

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 vorrausgesetzt). 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)

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, jpg 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 Diagrams legen.

Messfühler (vsn > 2.1)

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. Messfühler sind ab der Version 2.1 von expecco verfügbar.

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).

Beispiel.png

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-2016 eXept Software AG