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.
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
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?
09DEC10
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.
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.
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).
Jarek,
I agree. I rarely use Activity Diagram outside the business model.
Ok, understood :), like me.., but activity diagram is useful for documenting some operations (method algorithm ) …
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.
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.
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?
I think the actions don’t have a name at all
I’m a huge fan of the concept – never say never. Additionally, I think our responsibility in documenting design should consider the needs of the audiences as much as any standard or opinion of what is ‘right’. In this context, I think there is still a place for activities on activity diagrams though limited to encompassing process names at a high level without noting their respective actions. For instance consider the infamous ATM activity flow. An executive-level audience may only be interested in seeing the various processes involved by name (activities), without the details (actions) of what steps are actually necessary. While a business / QA / development audience would be interested in the individual actions to ensure requirements are met. In this case, you would have “Log in”, “Withdraw Cash”, or “Check Balance” as activities each respectively linked to child activity diagrams detailing the actual actions these processes entail thus satisfying the needs of both audiences. Last I checked, EA doesn’t allow linking child diagrams to action elements, but does for activities which is the basis of how we’ve been using it as noted. All that said. I also prefer sequence diagrams far more than activities.
Geert I’m trying to show on an Activity Diagram the object flows which output the Activity Parameters defined for the activity. I can’t see any way to put the actual Activity Parameters on the diagram – any advice?
Hello, I’ve just stumbled across this article (while in search of something completely different) but I would like to point out, that the advice itself is perhaps missing an important note or addendum (which may be somehow “hidden” behind the resume of the article “Activity: used to contain an Activity Diagram” but maybe not explicit enough): in my opinion, it depends on the LOD (Level-Of-Detail) you are currently on with regard to the context of the entire model. And I can imagine some high-level overview Activity Diagram that contains only Activities being then detailed more thoroughly in subsequent Activity Diagrams. The same applies on the element “Activity” itself – suddenly instead of an “Action” one realizes, that “Activity” is more appropriate, since the “Action” one is about to place on the diagram is far more complex than the other ones (especially the “Atomic” ones). So that is what I would perhaps dare suggest to add to the article itself.
EA forbids you to use control flow from Acton to Activity. I guess you either use activities or actions but not both into the same ACT – if you are to use activities at all. I am a bit confused…
You are not supposed to use Activities on an Activity Diagram ever. In recent versions EA has become more strict with the rules for control flows.
Hi Geert,
I’m trying to use actions as invocations to drill down into lower level diagrams as mentioned above, but I was wondering what the best way to do this is?
I’ve found two methods.
The first is to create an activity on the top level diagram, and then add the lower level as a composite diagram of the activity element. Then remove the activity element from the diagram and then re-add it as an invocation.
The second method is to create an activity element in the project browser and then move the diagram it relates to under the activity element so that the activity element is the diagrams “parent”. When the activity element is dragged onto the diagram, it can be placed as an action with an invocation.
Are either of these two approaches the right way to do it? If not, please can you describe the method you use.
Thanks
Worth mentioning that in order to add an Activity as an Action, you Control drag it from the Project Browser, and select Drop As “Invocation (Action). You can then select “Save selection as default” and “Hold Ctrl to Show this dialog. So by default you will always drag Actions