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

Short

Don’t use Activities on an Activity Diagram

Purpose

Model useful and UML compliant Activity Diagrams

Detail

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.

Checkout_simple_hor

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.

Checkout_DuplicatePayment

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.

Checkout_DuplicateDecision

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.

Checkout_Actions

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

Published by

Geert Bellekens

Freelance UML and Enterprise Architect consultant

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

  1. 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.

  2. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s