CompoundBlock Element/en
Inhaltsverzeichnis
Introduction[Bearbeiten]
A Compound Block describes an action's behavior via an activity diagram. The diagram is similar to dataflow 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[Bearbeiten]
Diagram elements are elements in an activity diagram. They are basically used to control the behavior of compound blocks and are manipulated in the network editor.
Introductory Activity Diagram Example[Bearbeiten]
The following example shows the major components of 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 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)[Bearbeiten]
A step is a block which is placed in 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. Aktually, 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).
Autostart (1)[Bearbeiten]
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 autostarted 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)[Bearbeiten]
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, 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)[Bearbeiten]
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)[Bearbeiten]
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)[Bearbeiten]
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)[Bearbeiten]
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.
Environment Freeze Value (5)[Bearbeiten]
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.
Annotation (2)[Bearbeiten]
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 (vsn2.1)[Bearbeiten]
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.
Relationship to Petri Nets[Bearbeiten]
--- to be written
Relationship to UML Activity Diagrams[Bearbeiten]
--- to be written
Back to the full online documentation: Online Documentation
The activity diagram which defines the behavior of a compound block is edited in the network editor. This is the "internal view" of the block. The interface of an compound block (e.g. number and type of pins) can be regarded as its "external view" and is defined in the schema editor.
For other tree elements see: Tree Elements
