CompoundBlock Element/en

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

Introduction

A "Compound Action Block" describes an action's behavior with an activity diagram. The diagram is similar to data flow diagrams as used in UML2.0 and also has many features in common with Petri Nets. The diagram consists of sub actions called steps. The execution is controlled via a combination of data and control flows. Data flows are defined as values (results, measurement values, objects, documents etc.) being passed from one step to another. Control flows are defined as "action finished" information being used to trigger another step's action. These flows are defined by interconnections from a step's output pin to another step's input pin.

Diagram Elements

Diagram elements are elements in an activity diagram. They define the behavior of the compound action block and are manipulated in the network editor.

Introductory Activity Diagram Example

The following example shows the major components of an activity diagram.

An activity diagram

The diagram models a test of an e-mail transmission:

  • First, the step "Create Unique ID" creates a so-called UUID at its output pin, which is used later to check whether the correct e-mail has arrived.
  • The UUID is delivered to the step "Send E-Mail [SMTP]", which sends an e-mail via SMTP ("Simple Mail Transfer Protocol") using the UUID as subject.
  • Next, the "Time [Delay]" step waits for 5 seconds.
  • Finally, "Check for incoming Mail" checks whether an e-mail has arrived with the given UUID as subject. If there is no such e-mail the test will fail.

Notice that the definition of activity diagrams in expecco corresponds largely with the UML notation. However, to emphasize important aspects and to make the diagram easier to read, some elements differ slightly from the standard UML notation. Especially, pin stereotypes are rendered directly as different pin style instead of adding extra "<<stereotype>>" labels.

Step (7)

A "step" is a action block which is placed into an activity diagram. These blocks can be either elementary blocks (such as "Create Unique ID") which are defined by a piece of source code or compound blocks (such as "Check Incoming Mail") which are defined by their own activity diagram. To the network where a block is placed, there is no difference in the behavior. The network which uses an action (i.e. places a step) does not need to know how the internals of the action are implemented. Actually, there is not even a visual difference in the diagram. All are triggered by the availability of input data, perform an operation, and generate results on their output(s).

Steps are described in detail in a separate document.

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 oriented vertically, whereas data-flow pins are oriented horizontally. Input pins are always located at the top or left, whereas output pins are located at the right or bottom.

Pins are rendered according to their behavior during execution; especially consuming vs. non-consuming input behaviour and buffered vs. non-buffered output behavior is drawn (filled vs. unfilled) to highlight these important facts.

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), and the left pins are always inputs, whereas the right pins are always outputs.

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), and pins at the top are always inputs, whereas pins at the bottom are always outputs.

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 and non-consuming (so called "parameter pin"). For details on triggering and consumption 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 and non-consuming (so called "parameter pin"). For details on triggering and consumption 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, JPEG or PNG images). You can highlight important parts of the diagram by using an empty text annotation with a non-white background color.

Probes

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.

Semantics

Relationship to Petri Nets

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

Relationship to UML Activity Diagrams

Compound actions in expecco are isomorph to UML activity diagrams with a particular predefined set of stereotypes for connections, pins and action steps. These stereotypes are hardcoded in expecco, and define the semantics of action triggering, queueing behaviour of data connections, and the optional parallel execution of steps. The graphical representation is slightly different, to replace the somewhat clumsy <<stereotype>> annotations by different pin images (filled/unfilled etc.). Also, all connections in expecco are object-connections, and all pins receive and generate objects as values.

Relationship to Flow Chart Diagrams

Activity diagrams can also 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.

Editors

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 a 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-2018 eXept Software AG