Activity diagrams: clearly present chrono­log­i­cal activity processes with UML

UML 2 specifies an activity as behavior that underlies sub­or­di­nate 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 con­junc­tion 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 ac­com­mo­dates edges (arrows) and nodes (rec­tan­gles). These symbolize the detailed actions, objects, and control or data flows of the activity.

Only if the con­di­tions 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 in­di­vid­ual 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 de­scrip­tions. Some of them are expressed in UML with their own notations. These are the subtypes of actions:

1. Opaque actions act as place­hold­ers or are specified by concrete text syntax (not defined by UML).
2. In­vo­ca­tion actions are actions that cause a certain behavior – directly or in­di­rect­ly. These include: 

• Call actions: a call behavior action directly in­sti­gates a behavior. A call operation action, on the other hand, sends a request to an object that in­sti­gates a related behavior. The start object behavior action directly causes an object to execute its instance behavior. If none is defined, it can trigger the high­er­lev­el class behavior (clas­si­fi­er behavior).
  
  The notation of an action that causes behavior consists of a rounded rectangle. This is where you enter the name of the behavior you want to instigate. Call behavior actions are also marked with a trident icon, as shown in the picture below. This is to represent the further hi­er­ar­chi­cal branching that results from the action.
   
• Send actions: Send actions in the activity diagram always send data asyn­chro­nous­ly (sequence diagrams also know syn­chro­nous 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 re­cip­i­ents 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 trans­mit­ted 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 clas­si­fi­ca­tion. 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 spec­i­fi­ca­tion actions” examine value spec­i­fi­ca­tions (the notation carries the label “value spec­i­fi­ca­tion”)
• “Read extent actions” find all objects of a class and objects from its spec­i­fi­ca­tions (for practical reasons, modelers usually limit the range)
• “Re­clas­si­fy object actions” change the class for the object on your input pin
• “Read is clas­si­fied object actions” determine whether an object on your input pin belongs to a class
• “Start clas­si­fi­er behavior actions” trigger a behavior for an object that is de­ter­mined by its class (the behavior is then asyn­chro­nous)

4. Link actions change the behavior of as­so­ci­a­tions (re­la­tion­ships between clas­si­fiers, usually two classes) and their instances, like links. These include:

• “Read link actions” retrieve values (link end data) on an as­so­ci­a­tion’s page
• “Create link actions” are actions that create links (they do not have output pins because links are not data them­selves) and link objects
• “Destroy link actions” delete links and link objects if they cor­re­spond to a specified link end data value

5. Link object actions influence the behavior of link objects, but view the objects from different per­spec­tives. 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 clas­si­fiers end values from link objects
• “Create link object actions” are special link actions that are used to create link objects

6. Struc­tur­al feature actions determine the behavior of struc­tur­al char­ac­ter­is­tics in activity diagrams. To do this, they require an input pin, since they are usually assigned both an object and a sta­t­i­cal­ly specified struc­tur­al char­ac­ter­is­tic of a clas­si­fi­er. The structure char­ac­ter­is­tic action affects both elements. The following types are available:

• “Read struc­tur­al feature action” reads the values of the structure char­ac­ter­is­tics and forwards them as output
• “Add struc­tur­al feature value actions” require a value input pin which specifies the value that the action assigns to a struc­tur­al feature
• “Remove struc­tur­al feature value actions” subtract a value from a struc­tur­al feature (a value input pin with mul­ti­plic­i­ty of 1. 1 specifies this value)

7. Variable actions influence sta­t­i­cal­ly specified variables defined by an activity or struc­tured 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 pre­scribed states occur. UML describes three spe­cial­iza­tions:

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

9. Struc­tured 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 behavior is de­ter­mined by activity nodes and edges, and on the other hand, that certain subtypes of these actions stipulate a certain behavior for the ex­e­cutable nodes due to their semantics – es­pe­cial­ly with regard to their sequence.

These are the subtypes of struc­tured actions:

• Con­di­tion­al nodes consist of one or more clauses that represent the different branches of the possible ex­e­cutable actions. A clause contains a test segment and a body segment, which in turn contain cutquan­ti­ty-free ex­e­cutable 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 al­ter­nate­ly.
• Sequence nodes impose an order on the ex­e­cutable 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 struc­tured activity nodes. You accept one or more col­lec­tions of values as input. On its way to the expansion region, the input pin copies each incoming token to the number of col­lec­tion elements. All inlying nodes process them­selves at each in­di­vid­ual value of the col­lec­tion. A run is con­sid­ered 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 col­lec­tion, on the inside, the in­di­vid­ual elements of the col­lec­tion are con­sid­ered as values. Draw a rounded rectangle with a dotted line for the notation. The expansion nodes appear as rec­tan­gles with segments and, as shown below, are drawn directly on the line. The seg­men­ta­tion should represent the list of value col­lec­tions.

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 in­tro­duced in the UML 2 activity diagram. They are typed elements. If an object node cor­re­sponds to a certain type, the object tokens that move on it must have cor­re­spond­ing 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 (behavior 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 rec­tan­gles 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 be­hav­ioral de­scrip­tion. According to UML, each behavior has pa­ra­me­ters. Before a behavior is executed, you can feed values into it for pro­cess­ing. New values are returned after pro­cess­ing. The pa­ra­me­ters in this structure are the place­hold­ers 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 sig­nif­i­cant dif­fer­ence 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 (es­pe­cial­ly 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 chrono­log­i­cal 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 im­me­di­ate­ly sets the control flow in motion. If several start nodes exist, the re­spec­tive control flows start si­mul­ta­ne­ous­ly. Struc­tured activity nodes can also have start nodes. These also start im­me­di­ate­ly when the struc­tured activity is ini­tial­ized, as long as no con­di­tions 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 de­stroy­ing 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 syn­chro­nous actions. Asyn­chro­nous 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 al­ter­na­tive if you model several end points in the activity diagram.

3. Par­al­leliza­tion nodes and syn­chro­niza­tion nodes (fork nodes and join nodes), also called forms, are control nodes with almost identical notations that mirror their tasks. A par­al­leliza­tion node divides an incoming activity edge into several, si­mul­ta­ne­ous­ly outgoing flows. Only one activity edge can enter the par­al­leliza­tion 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 des­ti­na­tion of the outgoing flow, the token is deleted from the source node. If another target does not accept its token, the par­al­leliza­tion node can stop the token until it is accepted

Syn­chro­niza­tion 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 spec­i­fi­ca­tion to the syn­chro­niza­tion node using “joinSpec,” the node waits for tokens that ex­plic­it­ly fulfill these re­quire­ments before issuing tokens.

4. Branching nodes and con­nect­ing nodes (decision nodes and merge nodes) also share the same symbol in the activity diagram. The flow control is one of the dis­tin­guish­ing 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.