Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Bill Egge on April 11, 2005, 06:52:58 pm
-
I am new to UML and have been reading about Activity diagrams and about deconstructing an activity with actions.
After reading, I decided to open some of my code and practice diagramming the actions.
I ran into a problem right away.
In UML there is the diamond which is a branch and the path to take depends on what the gaurd says.
But, I was trying to diagram this:
if NewLine <> '' then
Memo1.Lines.Add(NewLine);
DoSomething();
I do not understand how the IF statement gets diagrammed into the flow.
Can someone explain how UML says to diagram this?
Btw - DoSomething() sets NewLine to '', so the IF statement must be shown as executing before the DoSomething() function.
-
Hi,
this is not really a UML question as much as process flow question in general. There ALWAYS is an ELSE, it just may be "do nothing". See below:
(http://www.standardcase.com/SparxForum/condition.gif)
Hope this helps!
Bruno
-
At a very elementary level:
1: Add the diamond.
2: Add an action for Memo.Lines.Add()
3: Add a fork/join element
4: Add an action for DoSomething()
Add a flow between the diamond and the Memo.Lines.Add() and put a guard on it = Newline<>''
Add a flow between the diamond and the fork/join and put a guard on it = {else}
Add a flow between Memo.Lines.Add() and the fork/join.
Add a flow between the fork/join and DoSomething()
Pragmatically, most people leave out the explicit fork join and just have two flows coming into the DoSomething action and they also leave the {else} flow unguarded (i.e. else is imlied by a blank guard out of the diamond).
hth
bruce
Edit: Beat me by a second Bruno!
-
Bruno 1 : Bruce 1000...... the gap is getting narrower :-)
Edit: Beat me by a second Bruno!
-
Doesn't the EA online doc say the Fork/join bar is for threads (different concurrent flows of control) ?
A fork node is a control node that splits a flow into multiple concurrent flows.
A join node is a control node that synchronizes multiple flows.
If you want to explicitly merge flows after a branch ("choice"), you can use the diamond again.
-
Here are 2 diagrams. After reading the documentation it did seem that joins are used to synchronize threads and diamonds simply merge. So it seemed more appropriet to use a diamond. But I also saw examples where there was no diamond when 2 paths go in the same direction. I created 2 diagrams for each.
Diamonds:
This can also be used as a merge node in that multiple alternate flows can be merged (but not synchronized) to form one flow.
Joins:
The fork/join elements have different modes of use. These are as follows:
· To fork or split the flow into a number of concurrent flows.
· To join the flow of a number of concurrent flows.
· To both join and fork a number of incoming flows to a number of outgoing flows
Here is an image along with the source code it diagrams.
Does anyone see a problem with this? The one with the extra diamond seems like a lot of symbols to diagram something so simple.
Using Diamond (1 of 2)
(http://www.eggcentric.com/images/sparx/forum/XMLFormatter01.jpg)
Using no Diamond (2 of 2)
(http://www.eggcentric.com/images/sparx/forum/XMLFormatter02.jpg)
-
I don't use the merge diamond unless to make a point, I just have the two arrows converging on the same box.
Unfortunately EA doesn't manage connectors very tidily, and if you try to 'merge' the two arrows in the way you have done, if you move anything they will no longer stay aligned.
Shame you can't tell EA to merge the arrows at the end and keep them together.
Maybe I should request a Feature ...
[Don't try auto-arrange !!]