It's not an easy question to answer because there are many different ways to model the same thing, even within an activity diagram, and it depends on what subset of the notation you're using and what the model is for; if it's for simulation or code generation that's one thing, but if it's intended for a human reader it's another.
If it is for human consumption there is a very useful EA feature you can use for situations like this, namely Show Diagram in Frame.
What you do is you create a composite Activity for the little code snippet you've described, draw the branch and assignment in the composite diagram, and then in the parent diagram (which contains the composite Activity) right-click the Activity and select New Child Diagram -- Show Composite Diagram in Frame.
This will replace the regular presentation of the Activity with the composite diagram. But since it is still an Activity, you can select to display its parameters. Move those to the appropriate places around the border and you end up with something that's easy to read and understand.
In this case, I would draw the following in the composite diagram:
- A Decision with no name
- An Atomic Action "temp = y" with a ControlFlow from the Decision with a constraint [x < y]
- An Atomic Action "temp = x" with a ControlFlow from the Decision with a constraint [x >= y]
- A Merge with no name, with one ControlFlow from each Atomic Action above, no constraints
- An Atomic Action "theReturn = temp * inValue"
As you can see I'm omitting initial and final nodes, I'm not using WriteVariable Actions, just keeping it simple. The size of the resulting composite diagram is a factor, so you could even consider omitting the Merge if you like.
This approach works well for small snippets like the one you've described, but less well for large complex operations because the composite diagrams get too large.
HTH,
/Uffe
