Don’t use Activities on an Activity Diagram
Model useful and UML compliant Activity Diagrams
UML Activity Diagrams are often used to depict a certain flow of events. One of the reasons Activity Diagrams are so popular is because they are very similar to flow charts, something all of us know from long before UML even existed.
So lots of people start out enthusiastically to draw Activity Diagrams.
Lets say that we are modelling the checkout at a cash register of a store.
We start out with an InitialNode called Start and then we draw a ControlFlow to the Activity Scan Items. We then continue with the Activity Process Payment and end up in the FinalNode Finished.
So far so good, but now we want to deal with customers who need an invoice. In order to be able to print an invoice we need to ask the customer for its details such as name, address, VAT-number etc… After getting the company details we can process the Payment, and when the payment is finished we print the invoice.
When using Activities there are two possible solutions to model this workflow.
The first solution is to split up the flow into a Company flow and an Individual flow, but as you can see this would force us to duplicate the Process Payment activity; which is not acceptable of course. Duplicate elements very quickly turn your model into a maintenance nightmare.
Another solution would be to come back to the single Process Payment activity after registering the Company details.
But then we would need to split up the flow again after the Process Payment. This time we are not duplicating an activity but a decision, which is almost as bad. Another drawback is that this makes our activity diagram less readable because we can’t easily distinguish the two flows.
No the only real solution is to use Actions on the diagram instead of Activities.
Now all Activities have been replaced by Actions, and the Process Payment actions now both invoke the same Process Payment Activity.
- Activity: used to contain an Activity Diagram
- Action: used put on Activity Diagrams