How to visualize collaborative activities in an UML activity diagram?

Tim Meyer 0
Viewed 62

I'm currently stuck on modelling an activity diagram for a workflow which happens in a collaborative way by many users. It is somewhat comparable to multiple users editing and validating the same Confluence Page at the same time so I decided to use this as an example which is easy to understand.

The workflow for a single user would look like this:

The user edits a page (complex activity in my case), publishes it, then performs some kind of validation (another complex activity) on the published page. If unsatisfied, the user goes back to editing the page and repeats this cycle until satisfied.

Activity Diagram

Now imagine the collaborative version of it like this (this is a horrible workflow of course, but imagine you would have to model it anyway):

Several users edit the same page collaboratively, and at any point, one of the users can publish the current contents and start validating what has been edited so far. The other users will however stay in the editing step and might edit further content while the first user is validating. The "states" of the various users are independent from each other, so user 1 could start validating, then users 2 and 3 could publish changes and start validating as well while user 1 goes back to editing, during which user 4 publishes changes etc. The workflow will only end once all users have decided they don't want any further changes.

This leads to the question: How would I have to change the diagram to express the collaborative workflow I described here? Is the whole activity diagram a <<parallel>> expansion region? Do I add a synchronisation point at the end? Is it an <<iterative>> region instead? Or are the inner activities parallel, but not the whole workflow?

activity-diagram modeling uml architecture
2 Answers

If all the Example edit/validate cycles are independent, i.e. a user edits the page to make his/her changes and validate his/her changes independently, your current representation would be fine, since the workflow would start and end for each user independently.

If you wand to explicitly document that several users may start these activities in parallel, you need an "enclosing" activity diagram that shows the multi-user context without breaking the individual cycles. This activity would have a CallBehavioraction that calls Example the edit/validate cycle activity. To show the concurrency situation, you would indeed use an expansion region, or, better, the shorthand notation:

enter image description here

The little star seems like a type, but it means in fact that there are multiple concurrent executions of the activity:

(UML 2.5.1 specs, page 483): (...) instead of using a mode keyword, a “*” is placed in the upper right-hand corner of the symbol (this is intended to indicate “multiple execution.” The notation maps to an expansion region containing the CallBehaviorAction (as in Figure 16.50) with mode=parallel.

(Note: the missing closing parentheses in the quote is a typo in the specs).

If the edit/validate cycles are not that independent, for example if the validation would validate not only the local changes, but also the changes made by the others, it would be more complex:

  • First, you'd need to somehow explicit the collaborative editing or the merging of the changes with the others.
  • Then, if this revised model would allow to consider each "combined cycle" independently per user, the best is to use the same approach as above. But if not, you'd need to enclose it an expansion region. I have to admit that it's not clear to me if its mode should then be parallel or stream.
  • You'd then also need to clarify if a change by another user after the validation would require users having already validated to revalidate without having made any change. This might require a further enhancement of your initial cycle.
userPECf0

This is not really an answer, but too long for a comment. The issue is with your question itself.

Assume you have some content and two people edit it in parallel to correct typos at two different places. That could be handled trivially. But now assume the content has a contradiction that needs to be fixed. Say you have a statement A in the beginning and a conclusion with not A. Now you have two editors. This first will fix it to have overall A meaning and the second one will change it to be overall not A. There you have a clash.

There are lots of ways to handle that. And that's the point. You have to define these ways. Like you can build a car one by one sequentially, there is also a way to parallelize the build. But only according to strict rules. Without you simply end with a mess.

So what is the conclusion? Be clear on what you want to do and what your goal is. Only then start to deal with details. Not vice versa.

qwerty_so0
Related