Activity diagrams describe the actual workflow behavior of an information technology system. These diagrams are very similar to state diagrams because activities are the actual state of doing something. These diagrams describe the real state of the activities of a system showing the entire sequence of activities carried out. Also, these diagrams can show activities that are conditional or parallel.

When to use: activity diagrams

Activity diagrams should be used in concert with other modeling techniques, such as interaction diagrams and state diagrams. The main reason behind the use of these diagrams is to model the workflow behind the system being designed. These diagrams are also useful for analyzing a use case by describing what actions should be performed and when they should occur, describing a complicated sequential algorithm, and modeling applications with parallel processes.

Advantages of activity diagrams:

• The UML modeling language included that these diagrams are normally easily understood by both analysts and stakeholders.
• In UML for the IT Business Analyst, “The activity diagram is most useful for the IT BA to represent the workflow [because] It’s easy to understand, both for BAs and end users.”
• Because they are among the easiest to use diagrams available, they are generally considered an essential tool in an analyst’s repertoire.
• Additionally, as noted above, activity diagrams allow an analyst to display multiple conditions and actors within a workflow through the use of swimlanes. However, swimlanes are optional as usually only one condition or the actor is shown without them.

Disadvantages of activity diagrams:

The UML modeling language includes that these diagrams have the potential to become overly complex because their user-friendly nature can lend themselves to exhaustive description. In other words, since it’s so simple to display project-related information, why not include it all? When an analyst has a large project, creating a single diagram that is too complex can be a temptation.

However, as one author points out, “If you’re using activity diagrams to define the structure of a workflow, you shouldn’t try to explore multiple levels of activity graphs down to their most ‘atomic’ level.” Instead, an analyst should try to present a new diagram for each workflow or, if more applicable, use swimlanes to present different actors within the same workflow.

Another aspect of these diagrams is that they cannot be used in place of a state diagram or a sequence diagram because “activity diagrams don’t provide details about how objects behave or how objects collaborate.” This is not a disadvantage per se, but it is important for an analyst to keep it in mind when applying diagrams to his work.

In conclusion, activity diagrams are fairly easy to understand and will be useful for most projects because they clearly and moderately demonstrate how things work.” Unlike many diagramming techniques, these diagrams also allow for the representation of multiple options and actors within a workflow, and are easy to follow even for non-technical users

Activity Diagram Applications:

This diagram has been extended to specify flows between steps that transmit physical matter (eg, gasoline) or energy (eg, torque, pressure).

• Additional changes allow the diagram to better support continuous behaviors and continuous data flows.
• The UML 2 specification significantly expanded the functionality and scale of activity diagrams beyond their previous classification as a special case of state diagrams.
• Today, activity diagrams can be thought of as flowcharts of the 21st century, and UML modelers use activity diagrams to describe it.
• In addition, these diagrams are useful in the following methods:
• business rules
• Functions that occur in parallel
• Complex chain of multiple use cases
• Software flows and logic control settings
• Procedures with points of judgment and alternate flows
• Single use cases