UML Guide: Activity Diagrams

A use-case diagram describes the relationships between actions and discrete units of a system’s functionality. A use-case description provides a brief overview of the purpose of each use case and the steps required to complete that purpose. An activity diagram can be used to expand on a use-case description. Activity diagrams are similar to flow charts: they describe the order of activity and the branch logic of a process. However, they differ from traditional flow charts by allowing the representation of concurrent operations. Activities that take place simultaneously (such as threads) can be represented using activity diagrams. Activity diagrams can be used to supplement the use-case descriptions within a use-case model.

Creating activity diagrams

Activity diagrams flow from top to bottom. The initial state is represented by a closed circle. Activity proceeds through a series of activity states until it reaches its final state, which is represented by a closed circle inside an open circle.

Boxes with rounded corners represent activity states. Each activity state is labeled with a brief description of the activity it represents. The arrows between states, called transitions, represent the shift from one activity state to the next.

Conditionals

A conditional action in an activity diagram is an action that depends on one or more defined requirements. For instance, in the above Check Out Asset use-case, before an asset can be checked out, the system checks the patron’s account balance. If the patron’s account information indicates an unpaid overdue fine, the system enters an alternative thread of execution in which the library fine is paid. If no overdue fine is due, execution continues along the primary path. Conditionals are represented in activity diagrams with branches and merges.

Branches And Merges

Branches represent places where conditionals are used for decisions in the activity flow. When a transition enters a branch, a question is asked and a decision is made to continue the flow in one of two or more possible paths of execution. The paths exiting a branch are called alternative threads because execution continues along only one path.

Concurrency

While branches are useful for describing when there are two or more options to take, there are also situations where the action will flow along two or more paths at the same time. This is known as concurrency. For instance, considering the Check Out Asset usecase, when an asset is being checked out, there are two actions that must be performed at the same time: adding that asset to the patron’s account information and marking that asset as checked out. These situations are described in Activity Diagrams through forks and joins.

Forks And Joins

Forks and joins distinguish activity diagrams from traditional flow charts. When a transition enters a fork, execution branches off in two or more directions simultaneously. The threads exiting a fork operate concurrently. Threads converge at a join.

Activity diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.

Construction

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types:

• ellipses represent actions;
• diamonds represent decisions;
• bars represent the start (split) or end (join) of concurrent activities;
• a black circle represents the start (initial node) of the workflow;
• an encircled black circle represents the end (final node).

Arrows run from the start towards the end and represent the order in which activities happen.

Activity diagrams can be regarded as a form of a structured flowchart combined with a traditional data flow diagram. Typical flowchart techniques lack constructs for expressing concurrency. However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.

While in UML 1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x, the activity diagrams were reformalized to be based on Petri net-like semantics, increasing the scope of situations that can be modeled using activity diagrams. These changes cause many UML 1.x activity diagrams to be interpreted differently in UML 2.x.

UML activity diagrams in version 2.x can be used in various domains, e.g. in design of embedded systems. It is possible to verify such a specification using model checking technique.