Activity diagrams describe the actual work flow behavior of a system in Information Technology. Activity diagrams are very similar to state Diagrams because activities are the actual state of doing something. Activity diagrams describe the actual state of activities of a system by showing all the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel.

When to Use: Activity Diagrams

Activity diagrams should be used in alignment with other modeling techniques like interaction diagrams and State diagrams. The main reason behind using activity diagrams is to model the work flow behind the system being designed. Activity Diagrams are also useful for analyzing a use case by describing what actions need to take place and when they should occur, describing a complicated sequential algorithm and modeling applications with parallel processes.

Activity diagrams' advantages:

• UML modeling language included that activity diagrams are normally easily comprehensible for both analysts and stakeholders.

• According to ZaranTech in UML for the IT Business Analyst, "The activity diagram is the one most useful to the IT BA for depicting work flow [because] it is simple to understand—both for BAs and end-users."

• Since they are among the most user-friendly diagrams available, they are generally regarded as an essential tool in an analyst's repertoire.

• Additionally, as stated above, activity diagrams allow an analyst to display multiple conditions and actors within a work flow through the use of swimlanes. Swimlanes, however, are optional as a single condition or actor is normally displayed without them.

Activity diagrams’ disadvantages:

• UML modeling language include that activity diagrams have the potential to become overly complex because their user-friendly nature may lend itself to an all-inclusive description. In other words, since it is so simple to display the information related to the project, why not include all of it? When an analyst has a large project, creating a single, overly complex diagram can be a temptation.

• However, as one author notes, "if you are using activity diagrams to define the structure of a work flow, you should not attempt to explore several levels of activity graphs down to their most ‘atomic' level". Instead, an analyst should try to present a new diagram for each work flow, or if more applicable, to use swimlanes to present different actors within the same work flow.

• Another aspect of activity diagrams is that they may not be used in lieu of a state diagram or sequence diagram because "activity diagrams do not give detail about how objects behave or how objects collaborate." This is not a disadvantage per se, but it is important for an analyst to keep in mind when applying diagrams to their work.

In conclusion, activity diagrams are fairly easy to get the hang of, and will be useful for most projects because they plainly and moderately clearly demonstrate how things work." Unlike many diagramming techniques, activity diagrams also enable the depiction of multiple choices and actors within a work flow, and they are easy for even non-technical users to follow

Applications of activity diagram:

• The activity diagram has been extended to specify flows among steps that transmit physical matter (e.g., gasoline) or energy (e.g., torque, pressure).

• Additional changes allow the diagram to better support continuous behaviors and continuous data flows.

• The UML 2 specification significantly prolonged the features and scale of activity diagrams beyond their earlier classification as a special case of state diagrams.

• Today, activity diagrams can be thought of as flow charts for the 21st century, and UML modelers use activity diagrams to describe it.

• Also, these activity diagrams are useful in following methods:

• Business Rules

• Functions that occur in parallel

• Complex chain of multiple use cases

• Software flows and logic control configurations

• Procedures with judgment points and alternate flows

• Single use cases