Two approaches to structuring the Activity diagram

Comparison of two approaches for structuring the Activity diagram (based on “Protein”)

In the first part of the article "From modeling processes to designing an automated system," we modeled the processes of the "fairy-tale" subject area - lines about a squirrel from "The Tale of Tsar Saltan, about his son, the glorious and mighty bogatyr Prince Gvidon Saltanovich and about the beautiful princess Swans" A.S. Pushkin. And we started with the Activity diagram, agreeing on structuring the diagram field using the swim lanes - Swim lanes. The name of the track corresponds to the type of diagram elements that are present on this track: “Input and Output Artifacts”, “Process Steps”, “Participants” and “Business Rules”. This approach differs from the standard one when the tracks are designated by the names of the participants in the process, thus assigning them to certain areas of responsibility in the process.

In this example, I use the Enterprise Architect environment from the Australian company Sparx Systems [1].

In more detail about the applied approaches to modeling see [2].

The full UML specification is here [3].

I will repeat the diagram from the previous article (Figure 1) and show a redrawn diagram with “standard” tracks (Figure 2), I will try to highlight the pros and cons, perhaps a little subjectively.

Figure 1. Activity diagram - general view of the process.

Figure 2. Activity Chart - standard chart structuring

1. It must be admitted that the number of arrows is slightly less in the 2nd diagram.
2. But in the 2nd diagram, the objects are "smeared" across the entire field of the diagram, which, for my taste, is not very convenient.
3. Same story with notes - rules. And in order to insert the rule about the appointment of a deacon, we had to move all the elements of the diagram at some point down.
4. I had to clone the "receive / transmit ..." step to show that several participants are present at this step.
5. In the second variant, we had to abandon one branching and one merging process, well, it was absolutely impossible to put them in a “beautiful” way! For good, then it would be necessary to hang a comment - the rule.

There are no comrades to taste and color, of course, but the first version seems to me more convenient for collecting data on the process.

But I will not dissemble - sometimes it is better to draw both options in order to sort it out.

Addition. I thank for the comments and provide a slightly modified diagram of the 2nd option: you can rearrange the tracks (in Figure 2, their sequence repeats the order of appearance of the participants in the narration), the number of intersecting arrows will decrease slightly (Figure 3).

Figure 3. Activity Chart - standard chart structuring - tracks swapped

Articles based on which appeared this article:
From process modeling to designing an automated system (Part 1)
From process modeling to designing an automated system (Part 2)