Activity diagrams: clearly present chronological activity processes with UML

UML 2 specifies an activity as behaviour that underlies subordinate units (actions and objects) in an order. It uses data and control flow models to do this. The activity diagram can be displayed as part of a larger system in conjunction with other diagram types. A large, rounded rectangle indicates the activity as a closed system (can also be omitted). Below in the example image, you can see the activity “cooking asparagus.” The title is written in the header of the large rectangle. The body accommodates edges (arrows) and nodes (rectangles). These symbolise the detailed actions, objects, and control or data flows of the activity.

Only if the conditions set on the pins are met, will an action (input pin) be entered or will result (output pin). Even if an action has several incoming control flows, each individual must offer a token before an action starts.

For actions within an activity diagram, the abstract syntax contains the simple form of the rounded rectangle. However, there are specific actions that modelers can use for more precise descriptions. Some of them are expressed in UML with their own notations. These are the subtypes of actions:

1. Opaque actions act as placeholders or are specified by concrete text syntax (not defined by UML).
2. Invocation actions are actions that cause a certain behaviour – directly or indirectly. These include: 

• Call actions: a call behavior action directly instigates a behaviour. A call operation action, on the other hand, sends a request to an object that instigates a related behavior. The start object behaviour action directly causes an object to execute its instance behaviour. If none is defined, it can trigger the higherlevel class behaviour (classifier behavior).
  
  The notation of an action that causes behaviour consists of a rounded rectangle. This is where you enter the name of the behaviour you want to instigate. Call behaviour actions are also marked with a trident icon, as shown in the picture below. This is to represent the further hierarchical branching that results from the action.
   
• Send actions: Send actions in the activity diagram always send data asynchronously (sequence diagrams also know synchronous messages, for example). This means that they do not wait for a response from the target object and don’t block the object flow. The action ends as soon as the message has been sent. So, it can have an “argument” input e.g. parameter, but does not produce a “result” output. In addition, messages can be sent to several recipients at the same time. Send signal action, broadcast signal action, and send object action belong to this type.
  
  Send signal actions differ in their notation from the usual form (the rounded rectangle). Instead, a pentagon points like a large arrow in the direction of the transmitted signal. If the content of a send object action also consists of a signal, you can use the same notation.

3. Object actions change the state of objects (instances of a class). You can create or destroy them, compare them with other instances, read them, and then assign them to a class or change the classification. The following instances of object actions then exist in UML 2:

• “Create object actions” generate instances of a class i.e. objects
• “Destroy object actions” destroy the object on your input pin
• “Test identity actions” examine whether two values on your input pin represent the same object.
• “Read self actions” determine their own context object.
• “Value specification actions” examine value specifications (the notation carries the label “value specification”)
• “Read extent actions” find all objects of a class and objects from its specifications (for practical reasons, modelers usually limit the range)
• “Reclassify object actions” change the class for the object on your input pin
• “Read is classified object actions” determine whether an object on your input pin belongs to a class
• “Start classifier behavior actions” trigger a behaviour for an object that is determined by its class (the behaviour is then asynchronous)

4. Link actions change the behaviour of associations (relationships between classifiers, usually two classes) and their instances, like links. These include:

• “Read link actions” retrieve values (link end data) on an association’s page
• “Create link actions” are actions that create links (they do not have output pins because links are not data themselves) and link objects
• “Destroy link actions” delete links and link objects if they correspond to a specified link end data value

5. Link object actions influence the behaviour of link objects, but view the objects from different perspectives. These are instances of link object actions:

• “Read link object end actions” call up end objects from link objects
• “Read link object end qualifier actions” call up classifiers end values from link objects
• “Create link object actions” are special link actions that are used to create link objects

6. Structural feature actions determine the behaviour of structural characteristics in activity diagrams. To do this, they require an input pin, since they are usually assigned both an object and a statically specified structural characteristic of a classifier. The structure characteristic action affects both elements. The following types are available:

• “Read structural feature action” reads the values of the structure characteristics and forwards them as output
• “Add structural feature value actions” require a value input pin which specifies the value that the action assigns to a structural feature
• “Remove structural feature value actions” subtract a value from a structural feature (a value input pin with multiplicity of 1. 1 specifies this value)

7. Variable actions influence statically specified variables defined by an activity or structured activity node. There are three types:

• “Add variable value actions” also require a value input pin, but must be of the same type as the variable and adds exactly one value to it
• “Remove variable value actions” remove a value specified by the pin
• “Clear variable actions” remove all values of a variable

8. Accept event actions belong to the so-called wait points. This means that the action is waiting for an event from the event pool of the context object. The action has triggers that set off the action when one or more prescribed states occur. UML describes three specialisations:

• “Accept call actions” have a trigger that accepts call events: two result output pins and a return information output pin complete the arrangement (if a reply action is to be executed, store the necessary information in the return information output pin)

9. Structured actions declare UML 2 in the activity diagram both as actions and as an activity group (see above). This means, on the one hand, that their behaviour is determined by activity nodes and edges, and on the other hand, that certain subtypes of these actions stipulate a certain behaviour for the executable nodes due to their semantics – especially with regard to their sequence.

These are the subtypes of structured actions:

• Conditional nodes consist of one or more clauses that represent the different branches of the possible executable actions. A clause contains a test segment and a body segment, which in turn contain cutquantity-free executable nodes. First, the clause executes the action in the test area. If its output value is “true,” the clause executes the action in the body area.
• Loop nodes describe a group of actions that are repeated within a loop. The actions are divided into three sections: “setup,” “test,” and “body.” The loop always executes the “setup” first. This is followed by “test” or “body,” which is then repeated alternately.
• Sequence nodes impose an order on the executable node within their limits. You display these with data flows as activity edges (i.e. simple arrows). Edges can point freely into and out of the structure.

10. Expansion regions are another form of structured activity nodes. You accept one or more collections of values as input. On its way to the expansion region, the input pin copies each incoming token to the number of collection elements. All inlying nodes process themselves at each individual value of the collection. A run is considered an “expansion execution.” An expansion node (a type of object node) indicates the interface of the expansion region. On the outside, they display their values as a collection, on the inside, the individual elements of the collection are considered as values. Draw a rounded rectangle with a dotted line for the notation. The expansion nodes appear as rectangles with segments and, as shown below, are drawn directly on the line. The segmentation should represent the list of value collections.

Object nodes are subtypes of activity nodes. In general, an object in UML is the smallest instance with values. In the activity diagram, objects represent data. While an action is being executed, the object nodes hold this data. Because only control tokens can go directly through an action. Object tokens, on the other hand, are received as a value for an input pin and are forwarded by the output pin on the object flow.

Object nodes were first introduced in the UML 2 activity diagram. They are typed elements. If an object node corresponds to a certain type, the object tokens that move on it must have corresponding values. An exception are null tokens that manage without a value – they conform to each object node.

Object nodes dictate the sequence in which tokens leave them. There are four ways to do this:

• Unordered (not specified)
• Ordered (behaviour defined by the modeler)
• FIFO (first in first out): the order of entry and exit remains the same
• LIFO (last in first out): the order is exactly the opposite

If you want to create an activity diagram, you have four types of object nodes to choose from for modeling:

1. The pin: Pins have already been cut in this version. In the first graphic, the basic notation of pins is shown. Due to their function as a link between action flows and object flows, modelers usually draw them as small rectangles directly on the action symbol. Input pins are marked with an arrow (i.e. an edge or an object flow) in the direction of the action. For output pins, the arrow leads away from the action. The following graphic shows how you can shorten pins of the same type (left) or how you can draw input and output pins if you omit the edges (right).

2. Activity parameter node: The activity belongs to the metaclass of the behavioral description. According to UML, each behaviour has parameters. Before a behavior is executed, you can feed values into it for processing. New values are returned after processing. The parameters in this structure are the placeholders that allow these values to be entered or issued. The activity parameter node performs this task for the UML activity diagram. This means that activity parameter nodes are at the beginning and end of an activity.
   
   As a result, nodes like these either have only incoming or only outgoing activity edges. Input activity parameter nodes are drawn with outgoing edges, and output activity parameter nodes with incoming edges. There is one activity parameter node for each parameter, both of which have the same type.

Within a UML activity diagram, tokens move through various actions until the activity is completed by the first token arriving at the end node. Since several tokens can pass through this process at the same time, a certain order is required. Use control nodes to ensure a clear process flow. These only manage control flows along your path from the beginning of the activity diagram through the actions to the end of the activity. Control nodes cannot cache tokens, unlike object nodes such as the buffer node.

A significant difference between object and control flows is that only control tokens migrate on control flows. Unlike object tokens, these tokens do not carry any data. They are merely markers. So, actions do not require object nodes (especially pins) to accept and pass on control tokens. A control token starts an action, moves to the next one and then sets it in motion. It controls the chronological execution of the activity.

Among the UML activity diagram symbols, the control nodes are probably the most diverse. They belong to the activity nodes. Here are six types of UML 2:

1. Start nodes (initial nodes) start an activity. When an activity starts, the start node immediately sets the control flow in motion. If several start nodes exist, the respective control flows start simultaneously. Structured activity nodes can also have start nodes. These also start immediately when the structured activity is initialised, as long as no conditions for the start have been set. Since initial nodes are at the beginning, all their edges are outgoing activity edges. These are always control flaws.
   
   Another special feature of starting nodes: The control tokens placed on the start node at the beginning of an activity can stay there if the control flow does not accept the offered token or is blocked.
    
2. End nodes end the flow of an activity. There are two types of end nodes: The activity final node ends the entire activity by destroying all tokens within the activity when the first token arrives. Only object tokens in the output of activity parameter nodes are retained. It also stops all synchronous actions. Asynchronous actions run until they are completed. End nodes accept all incoming tokens. Unlike the start node, an end node only has incoming activity edges. More than one end node is possible.
   If you draw an activity diagram with more than one end node, actions might possibly stop before they have served their purpose, because a token has already reached the first end point. The flow final node stops a control flow and destroys all incoming tokens. This does not affect other control flows. This end node is a practical alternative if you model several end points in the activity diagram.

3. Parallelisation nodes and synchronization nodes (fork nodes and join nodes), also called forms, are control nodes with almost identical notations that mirror their tasks. A parallelisation node divides an incoming activity edge into several, simultaneously outgoing flows. Only one activity edge can enter the parallelisation nodes. If it is a control flow, all outgoing edges are also control flows; the same principle applies to object flows. The node creates copies of the incoming token for all outgoing flows. If a token is accepted at the destination of the outgoing flow, the token is deleted from the source node. If another target does not accept its token, the parallelisation node can stop the token until it is accepted

Synchronisation nodes work exactly the other way round. Several edges run into them, but only one edge runs out. If all of the incoming edges consist of control flows, this is how a control flow leaves the node. If there is only one object flow below it, UML specifies the outgoing edge as the object flow. If control tokens are also received in this case, they expire and only object tokens run out. If two objects have the same identity, the node merges them into one token. Generally, tokens only run out when all incoming edges offer one (“and” operation). This takes place under the “first in first out” principle. If you assign a value specification to the synchronization node using “joinSpec,” the node waits for tokens that explicitly fulfill these requirements before issuing tokens.

Branching nodes and connecting nodes (decision nodes and merge nodes) also share the same symbol in the activity diagram. The flow control is one of the distinguishing features of these node notations. A branching node requires at least one, or two incoming edges at the most. UML names one the “primary incoming edge” and the second is called “decision input flow.” Whether outgoing flows represent object or control flows depends on the type of primary edge. The task of the node is to choose between outgoing edges. The node offers its inbound node without copying it. So the token can only take one way.