How to represent an action available from multiple swimlanes in an activity diagram?

user_8035772 0
Viewed 1323

I have an activity diagram where I have created swimlanes based on user roles. So when some actions are available to multiple roles, how can I represent it with a single action without repeating the action in each roles?

For example, in the diagram bellow, View Examination action can be performed by both Admin and Student, so I have two View Examinations actions, one for each of those roles. I want to remove this redundancy in my diagram because in the future there is going to be a lot of actions that multiple roles can perform.

enter image description here

activity-diagram roles uml
2 Answers

I guess you can not avoid it.

An activity diagram represents a process or a sequence of actions done by different entities. So if in your process both the admin and the student view the examinations, you have to depict it two times. My question would be more do you really need to depict that both the admin and the student view the examinations in the same process? Maybe you need two different processes one with the admin looking at the exminations and making some actions and another with the user/student still looking at the examination but doing another set of actions? Or maybe the admin looks at the examination like any other user (student/professor) so in this case you do not need it in the admin swinlane...

Hoping it helps, EBR

user_13287530

What you call "swimlane" for "roles" is in UML jargon called a "partition":

An ActivityPartition is a kind of ActivityGroup for identifying ActivityNodes that have some characteristics in common. ActivityPartitions can share contents.

So yes, you can have an activity node repeated in each partition. Especially, if it is executed by different classifiers. But UML offers many freedoms for representing partitioning. One of its solution seems well adapted for your case:

In some diagramming situations, using parallel lines to delineate ActivityPartitions is not practical. An alternative is to place the partition name in parenthesis above the ActivityNode name (...) A comma-separated list of partition names means that the node is contained in more than one partition.

So you could have 2 main partitions: System and Users, and in the second one, you could use the alternate notation to indicate a sub-partitioning:

+------------------------+-----------------------------------------+
|          System        |         Users                           |
+------------------------+-----------------------------------------+
|                        |                                         |
|                        |    +---------------------+              |
|                        |    |      (Admin)        |              |
|                        |    | Hit creation button |              |
|                        |    +---------------------+              |
|        ...             |      ...                                |
|                        |           +--------------------------+  |
|                        |           | (Admin, Student,Teacher) |  |
|                        |           |     View examinations    |  |
|                        |           +--------------------------+  |
|                        |                                         |
+------------------------+-----------------------------------------+

This is very practical for conveying the information about the involved/interested/execution roles, without unnecessary redundancy and without struggling for the ideal graphical layout.

Another way, could be an activity node drawn across a boundary. Most readers will immediately understand it. But this is formally not UML as far as I know, and some tools will not allow to draw it this way. Moreover, if you have more than two actors, it might be very difficult to find a suitable layout, e.g. if some nodes are across Admin/Student/Teacher, some across Admin/Student, and some across Admin/Teacher. So better follow proper UML which allows you to flexibly cope with such situations.

Not directly related: there is probably an issue with your current diagram anyway: the fork does not mean that both roles CAN do the relevant action, but that both WILL do. The arrows in the last column show that despite the fork, there will never be a join, so the first of Admin or System that will reach an activity-end node might brutally interrupt the Student/teacher viewing, which is certainly not what you intend to express.

user_37234230
Related