Activity Diagrams Guidelines revisited

Posted: 2006-07-26 09:03 | More posts about uml

Last year, after reading a book about UML, I wrote a set of posts with distilled UML guidelines. Now it is the time to look at them again and put some comments on usage.

Place the start point in the top-left corner.
I tend to create vertical activity diagrams, so I usually place the start on top and in center. This way looks more visual.
Include an ending point.
What? No ending point? So activity never ends? I always have at least one ending point
Simplify operations requiring flow charts.
The whole goal of activity diagrams is to visualize and, if possibly, simplify the process.
Question “black-hole” activities. Question “miracle” activities.
I would question any activities. It is very usual to have some unneccesary work only because analyst and/or client do not fully understand what is needed and what is achievable
Reflect the previous activity by using decision points.
Avoid superfluous decision points.
Ensure that each transition leaving a decision point has a guard.
If there is no guard then what this flow is trying to decide?
Do not overlap guards.
Huh?
Ensure that guards on decision points form a complete set.
And if they not - why do you have decision point, by the way?
Ensure that exit transition guards and activity invariants form a complete set.
Apply an [otherwise] guard for “fall-through” logic.
This one support the thesis about having the complete set of the guards next to each decision point.
Model guards only if they add value.
If you don't have real guards - you should not have the decision point in this place
Ensure that forks have corresponding joins.
Not always true - some of the forked processes may be terminated before they go to the join. Messaging is a good example.
Ensure that a fork has only one entry transition.
Ensure that a join has only one exit transition.
Avoid superfluous forks.
Order swimlanes in a logical manner.
It is all about logic, why say more?
Apply swimlanes to linear processes.
Have less than five swimlanes.
I would say that is you trying to add fourth swimlane, you are already creating something bigger, than anybody in your team can comprehend without asking you more questions. It is time to simplify the activity.
Consider swimareas for complex diagrams.
Consider to use UML2 and include sub-activities in this activity
Reorganize into smaller activity diagrams when swimareas include several activities.
Yes, very good point.
Consider horizontal swimlanes for business processes.
Well, it depends on business process and your preference.
Model the key activities in the primary swimlane.
Good point. If you don't have key activities in the primary swimlane chances are that you modeling incorrect activity.
Place shared action objects on swimlane separators.
Apply state names when an object appears several times.
Reflect the life-cycle stage of an action object in its state name.
And use color, if your modelling program allows it.
Show only critical inputs and outputs.
Depict action objects as smaller than activities.