UML Best Practice: There are no Activities on an Activity Diagram


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.

To conclude:

  • Activity: used to contain an Activity Diagram
  • Action: used put on Activity Diagrams

More UML best practices

13 thoughts on “UML Best Practice: There are no Activities on an Activity Diagram

  1. Geert:

    Do events “occur” or “flow”?

    What is it that flows along the arrow lines? Why is it that they are usually NOT labeled?

    If you do not use swim lanes, don’t you need to show who performs the process named in the soft-rectangle?

    For what processes are Activity Diagrams better suited say with ref to Communication Diagrams or Sequence Diagrams? When are they NOT necessary?


    1. Hi there.

      Just for information. In UML 2.0 the specification talks about ‘Tokens flowing between Nodes along Edges’. A Token can be a ‘Control Token’ or an ‘Object Token’. I found this a bit strange at first but it actually works very well. So the ‘Edge’ is the arrowed line.

      Hope this is of interest/help.

      1. Thank you Ian.
        Indeed. The ControlFlows I’ve drawn on the diagrams are actually a subtype of the abstract ActivityEdge. They are specific in that way that they can only be used by Control Tokens and not by Object Tokens.

  2. IMHO sequence diagram is more better for documenting and testing application logic: “flow” of internal software actions. After number of attempts for using activity diagram to documenting domain classes behavior (components) I dropped of activity diagram (for business flows I use BPMN).

  3. Geert,
    I’m glad to se that a conclusion I reached during recent exam preparation has confirmation in others suggestions.
    In the past I was using activities extensively on activity diagrams, encountering from time to time the problem you describe here. However, recently I realised that there should be only one activity on activity diagram – the one we are modelling (!). All other elements are action that invoke activities. The problem is that many books suggest (incorrectly) that activity is something complex while action is something simple.
    One of problems I see here is that EA actually strongly (probably unconciously) encourages using activities rather than actions. To put activity on a diagram one only need to single click on activity icon an click once on diagram and – there you go. In the meantime when creating action one need to answer first some additional questions (one or two depending on earlier answers). Moreover there is a composite activity (also mentioned in UML spec.) that in my opinion doesn’t make sense and that even further suggests that using activities instead of actions is OK. If you use actions on activity diagram, you’ll NEVER use complex activity (!).
    To make matter even worse, EA has significant bugs (at least in version 10 – I hardly tried it in earlier version, however one bug was non-existant there for sure – I’ll mention it later). First – when you import activity into diagram as action invoking that activity, the pins that are generated are always set to default “input” type instead of matching parameters in/out types. It forces additional work for modeller. Second – the activity may have no in parameters (resulting in no input action pins for the respective action) and in such case it should be possible to create a control flow directing the action itself (not the action pin). In EA v. 10 the actions that are created as activity invocation can be accesed only via action pins (!) so you’ve got to create fake input pin. This bug didn’t occur in v.9 and earlier, probably because there was no validation here at all. Of course similar problem can occur when there is no out parameter/output pin for the activity/action respectivelly.

  4. Thanks for the tip. I’ve been trying out both usages and hadn’t come to any conclusions yet. I’ll put this recommendation to practice and see how it works.

  5. How did you remove each of the the action names and just show the referenced Activity “Process Payments” in your diagram for the call behavior actions?

Leave a Reply