Flowchart diagrams vs. UML activity diagrams

What is the practical difference between using flowchart diagrams and UML activity diagrams? I have some thoughts, but maybe I'm missing an elephant in the room?

Flowchart diagram:

1. Widely used;
2. Easily understood by non-programmers;
3. Old?

UML Activity diagram:

1. Standardized;
2. Supports concurrency;
3. Less known syntax, but still simple enough.

For my case of ad-hoc documenting a particular block of application logic, I decided to go with the flowchart diagrams. More people in the company will be able to understand them.

Solution 1:

It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.

Solution 2:

As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation.

Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.

Activity diagram by ​spanish Wikipedia user Gwaur CC BY-SA 3.0, via Wikimedia Commons:

Solution 3:

According to the Agile Modeling site:

In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

From IBM:

However, flow charts do not include And states, and flow charts for operations cannot receive events.

Probably this is why flow charts are easier to understand because activity diagrams have the notion of object-oriented development and concurrency.

Solution 4:

You can generate source code from UML, and vice versa; hence the "standardized" characteristic you talked about.

Solution 5:

UML in itself is used to share your understanding. Share the understanding in a standardized way. Since your case is ad hoc and the primary usage of an UML diagram is to provide an informal sketch, activity diagram can be used here. But so can flow charts as there are no parellism involved here. I have always found the following argument to be helpful. The artifct that i am producing is going to benefit whom? And can i express the flow in a self explanatory way using a flow chart. And if yes, then you should go ahead and use flow chart. But if your class diagrams, sequence etc are in UML format, it would make sense to have your activity diagrams in UML as well for consistency sake(The argument here would be, if people can understand class,sequence UML semantics, then y not activity diagrams.).