Encyclopedia of Database Systems

Living Edition
| Editors: Ling Liu, M. Tamer Özsu

Activity Diagrams

  • Luciano BaresiEmail author
Living reference work entry
DOI: https://doi.org/10.1007/978-1-4899-7993-3_9-2

Definition

Activity diagrams, also known as control flow and object flow diagrams, are one of the UML (Unified Modeling Language [11]) behavioral diagrams. They provide a graphical notation to define the sequential, conditional, and parallel composition of lower-level behaviors. These diagrams are suitable for business process modeling and can easily be used to capture the logic of a single use case, the usage of a scenario, or the detailed logic of a business rule. They model the workflow behavior of an entity (system) in a way similar to state diagrams where the different activities are seen as the states of doing something. Although they could also model the internal logic of a complex operation, this is not their primary use, and tangled operations should always be decomposed into simpler ones [1, 2].

An activity [3] represents a behavior that is composed of individual elements called actions. Actions have incoming and outgoing edges that specify control and data flow from and to other nodes. Activities may form invocation hierarchies by invoking other activities, ultimately resolving to individual actions.

The execution of an activity implies that each contained action be executed zero, one, or more times depending on the execution conditions and the structure of the activity. The execution of an action is initiated by the termination of other actions, the availability of particular objects and data, or the occurrence of external events. The execution is based on token flow (like Petri nets). A token contains an object, datum, or locus of control and is present in the activity diagram at a particular node. When an action begins execution, tokens are accepted from some or all of its input edges, and a token is placed on the node. When an action completes execution, a token is removed from the node, and tokens are moved to some or all of its output edges.

Historical Background

OMG (Object Management Group, [10]) proposed and standardized activity diagrams by borrowing concepts from flow-based notations and some formal methods. As for the first class, these diagrams mimic flowcharts [6] in their idea of step-by-step representation of algorithms and processes, but they also resemble data and control flow diagrams [4]. The former provide a hierarchical and graphical representation of the “flow” of data through a system inspired by the idea of data flow graph. They show the flow of data from external entities into the system, how these data are moved from one computation to another, and how they are logically stored. Similarly, object flow diagrams show the relationships among input objects, methods, and output objects in object-based models. Control flow diagrams represent the paths that can be traversed while executing a program. Each node in the graph represents a basic block, be it a single line or an entire function, and edges render how the execution moves among them.

Moving to the second group, activity diagrams are similar to state diagrams [8], where the evolution of a system is rendered by the identification of the states, which characterize the element’s life cycle, and of the transitions between them. A state transition can be constrained by the occurrence of an event and by an additional condition; its firing can cause the execution of an associated action. Mealy, Moore, and Harel propose different variations: Mealy assumes that actions be only associated with transitions, Moore only considers actions associated with states, and Harel’s state charts [7] merge the two approaches with actions on both states and transitions and enhance their flat model with nested and concurrent states.

The dynamic semantics of activity diagrams is clearly inspired by Petri nets [9], which are a simple graphical formalism to specify the behavior of concurrent and parallel systems. The nodes are partitioned into places and transitions, with arcs that can only connect nodes of different type. Places may contain any number of tokens, and a distribution of tokens over the places of a net is called marking. A transition can only fire when there is at least a token in all its input places (i.e., those places connected to the transition by means of incoming edges), and its firing removes a token for all these places and produces a new one in each output place (i.e., a place connected to the transition through an outgoing edge). P/T nets only consider tokens as placeholders, while colored nets augment them with typed data and thus with firing conditions that become more articulated and can predicate on the tokens’ values in the input places.

Activity diagrams also borrow from SDL (Specification and Description Language, [5]). This is a specification language for the unambiguous description of the behavior of reactive and distributed systems. Originally, the notation was conceived for the specification of telecommunication systems, but currently its application is wider and includes process control and real-time applications in general. A system is specified as a set of interconnected abstract machines, which are extensions of finite state machines.

Scientific Fundamentals

Figure 1 addresses the well-known problem of order management and proposes a first activity diagram whose aim is twofold: it presents a possible formalization of the process, and it also introduces many of the concepts supplied by these diagrams.
Fig. 1

Example activity diagram

Each atomic step is called action, with an initial node and activity final nodes to delimit their ordering as sequences, parallel threads, or conditional flows. A fork splits a single execution thread into a set of parallel ones, while a join, along with an optional join specification to constrain the unification, is used to re-synchronize the different threads into a single execution. Similarly, a decision creates alternative paths, and a merge reunifies them. To avoid misunderstandings, each path must be decorated with the condition, in brackets, that must be verified to make the execution take that path.

The diagram of Fig. 1 also exemplifies the use of connectors to render flows/edges that might tangle the representation. This is nothing but an example, but the solution is interesting to avoid drawing flows that cross other elements or move all around the diagram. Another key feature is the use of a rake to indicate that action fill order is actually an activity invocation and hides a hierarchical decomposition of actions into activities.

Besides the control flow, activity diagrams can also show the data/object flow among the actions. The use of object nodes allows users to state the artifacts exchanged between two actions, even if they are not directly connected by an edge. In many cases, control and object flows coincide, but this is not mandatory.

Activities can also comprise input and output parameters to render the idea that the activity’s execution initiates when the inputs are available, and produces some outputs. For example, activity fill order of Fig. 2, which can be seen as a refinement of the invocation in Fig. 1, requires that at least one request be present, but then it considers the parameter as a stream and produces shipment information and rejected items. While the first outcome is the “normal” one, the second object is produced only in case of exceptions (rendered with a small triangle on both the object and the flow that produces it). In a stream, the flow is annotated from action compose requests to the join with its weight to mean that the subsequent processing must consider all the requests received when the composition starts.
Fig. 2

Activity diagrams with swim lanes

The execution can also consider signals as enablers or outcomes of special-purpose actions. For example, Fig. 2 shows the use of an accept signal, to force that the composition of orders (compose orders) be initiated by an external event, a time signal, to make the execution wait for a given timeframe (be it absolute or relative), and a send signal, to produce a notification to the customer as soon as the action starts.

Basic diagrams can also be enriched with swimlanes to partition the different actions with respect to their responsibilities. Figure 3 shows a simple example: The primitive actions are the same as those of Fig. 1, but now they are associated with the three players in charge of activating the behaviors in the activity. The standard also supports hierarchical and multidimensional partitioning, that is, hierarchies of responsible actors or matrix-based partitions.
Fig. 3

Example signals

The warehouse can also receive cancel order notifications to asynchronously interrupt the execution as soon as the external event arrivers. This is obtained by declaring an interruptable region, which contains the accept signal node and generates the interrupt that stops the computation in that region and moves the execution directly to action cancel order by means of an interrupting edge. More generally, this is a way to enrich diagrams with specialized exception handlers similarly to many modern programming and workflow languages. The figure also introduces pins as a compact way to render the objects exchanged between actions: empty boxes correspond to discrete elements, while filled ones refer to streams.

The discussion so far considers the case in which the outcome of an action triggers a single execution of another action, but in some cases, conditions may exist in which the “token” is structured and a single result triggers multiple executions of the same action. For example, if the example of Fig. 1 were slightly modified and after receiving an order, the user wants to check the items in it, a single execution of action receive order would trigger multiple executions of validate item. This situation is depicted in the left-hand side of Fig. 4, where the star * renders the information described so far.

The same problem can be addressed in a more complete way (right-hand side of figure) with an expansion region. The two arrays are supposed to store the input and output elements. In some cases, the number of input and output tokens is the same, but it might also be the case that the behavior in the region filters the incoming elements.
Fig. 4

Expansion region

In the left-hand side of Fig. 4, it is assumed that some items are accepted and fill the output array, while others are rejected and thus their execution flow ends there. This situation requires that a flow final be used to state that only the flow is ended and not the whole activity. Flow final nodes are a means to interrupt particular flows in this kind of regions but also in loops or other similar cases.

The execution leaves an expansion region as soon as all the output tokens are available, that is, as soon as all the executions of the behavior embedded in the region are over. Notice that these executions can be carried out both concurrently (by annotating the rectangle with stereotype concurrent) or iteratively (with stereotype iterative). The next action considers the whole set of tokens as a single entity.

Further details about exceptions and other advanced elements like pre- and post-conditions associated with single actions or whole activities, central buffers, and data stores are not discussed here, but the reader is referred to [11] for a thorough presentation.

Key Applications

Activity diagrams are usually employed to describe complex behaviors. This means that they are useful to model tangled processes, describe the actions that need to take place and when they should occur in use cases, render complicated algorithms, and model applications with parallel and alternative flows. Nowadays, these necessities belong to ICT specialists, like software engineering, requirements experts, and information systems architects, but also to experts in other fields (e.g., business analysts or production engineers) that need this kind of graphical notations to describe their solutions.

Activity diagrams can be used in isolation, when the user needs a pure control (data) flow notation, but they can also be adopted in conjunction with other modeling techniques such as interaction diagrams, state diagrams, or other UML diagrams. However, activity diagrams should not take the place of other diagrams. For example, even if the border between activity and state diagrams is sometimes blurred, activity diagrams provide a procedural decomposition of the problem under analysis, while state diagrams mostly concentrate on how studied elements behave. Moreover, activity diagrams do not give details about how objects behave or how they collaborate.

Cross-References

Recommended Reading

  1. 1.
    Arlow J, Neustadt I. UML 2 and the unified process: practical object-oriented analysis and design. 3rd ed. Boston: Addison-Wesley Professional; 2005.Google Scholar
  2. 2.
    Booch G, Rumbaugh J, Jacobson I. The unified modeling language user guide. 2nd ed. Boston: Addison-Wesley Professional; 2005.Google Scholar
  3. 3.
    Fowler M. UML distilled: a brief guide to the standard object modeling language. 3rd ed. Boston: Addison-Wesley Professional; 2003.Google Scholar
  4. 4.
    Gane C, Sarson T. Structured system analysis. Englewood Cliffs: Prentice-Hall; 1979.Google Scholar
  5. 5.
    Gaudin E, Najm E, Reed R. Proceedings of SDL 2007: Design for Dependable Systems, 13th International SDL Forum, Paris, Sept 2007, vol. 4745. Lecture Notes in Computer Science; 2007.Google Scholar
  6. 6.
    Goldstine H. The computer from Pascal to Von Neumann. Princeton: Princeton University Press; 1972. p. 266–67.zbMATHGoogle Scholar
  7. 7.
    Harel D, Naamad A. The STATEMATE semantics of statecharts. ACM Trans Softw Eng Methodol. 1996;5(4):293–333.CrossRefGoogle Scholar
  8. 8.
    Hopcroft J, Ullman J. Introduction to automata theory, languages, and computation. Harlow: Addison-Wesley; 2002.zbMATHGoogle Scholar
  9. 9.
    Murata T. Petri nets: properties, analysis, and applications. Proc IEEE. 1989;77(4):541–80.CrossRefGoogle Scholar
  10. 10.
    Object Management Group. http://www.omg.org/
  11. 11.
    OMG. Unified modeling language. http://www.uml.org/

Copyright information

© Springer Science+Business Media LLC 2017

Authors and Affiliations

  1. 1.Dipartimento di ElettronicaInformazione e Bioingegneria – Politecnico di MilanoMilanoItaly

Section editors and affiliations

  • Barbara Pernici
    • 1
  1. 1.Dept. di Elettronica e InformazionePolitecnico di MilanoMilanItaly