Control Flows on Activity Diagrams?

[jeshaw2]

I've figured out how to add an Object Flow line on an activity diagram, but how does one add a Control Flow line?

[«Midnight»]

I get the impression that EA considers those lines which are not object flows to be control flows.

I did some work via the automation interface and inspection of the database to support this assumption (not quite an "assertion" as yet). That was about 18 months ago, and I don't have it handy just now, so cannot say exactly what gave me the impression. Still, this may point you to what Sparx was thinking.

[Bruno.Cossi]

In the Activity Toolbox, I see both Object Flow and Control Flow, I can add both of them with no problem... am I missing something?

Bruno

[«Midnight»]

Right Bruno,

You're not missing anything here. My memory of this dates back to versio 4.1 at least. 6.1 has the buttons and adds the expected links. I also note that the tool tip for the control flow identifies it as such. The database also lists the links as ObjectFlow and ControlFlow.

It may have been that the buttons were labelled differently, either on the toolbar, or on the diagram, in the earlier version. I do distinctly remember wondering where control flow could be found back then.

Jim, Thomas and I have been discussing 'missing' tool bar buttons. It may be that you have to explicitly add the button in Tools / Options. I have noticed that button settings don't always get saved unless you click "Save Folder List" - it seems to be enough to click it before changing any buttons, but you have to do so.

Let me know if this is the problem. I'm trying to get a more precise sense of the bug, in order to make a better bug report.

David

[jeshaw2]

Well, I've discovered several things.

• I'm not sure why Sparks has selected some of  the element configurations they did for the various user perspectives
• The EA help file points one to the Link drop-down on the menu bar for a list of all possible links.  Control flows are not there.
• You can't change those element selections via the tools/options route.  One must right-click on the toolbox window's title bar to open the options of redefining the perspectives
• Saving the changed toolbox button set (Activity for instance) does not update the displayed buttons.  You must manually cause a repaint of the button list.
• One must use the little triangle buttons on the diagram names above and below the Activity diagram element set to scroll the Activity element list.  OK, I'm  dummy on this one   !
  

Not yet intuitively easy...

[«Midnight»]

Jim,

try what I suggested: click the Save Folder List button. This causes EA to update the toolbar set. The effect is probably the same as what you are getting, but at least it all happens in the Options dialog.

Yes, I know I can do this on my own, but I'd like to see if anyone else's EA behaves the way mine does.

As to the rest of your connector problems, sadly I have little more to add.

David

[jeshaw2]

try what I suggested: click the Save Folder List button.

I don't seem to have such a button.  Closest I have (or can find)  is Save Changes  which I must click in order to persist my changes.

Where is this button to which you refer?

[thomaskilian]

Jim,
I recently have a thread with Perspectives (talking to Jacek). While trying to solve his problem (he missed some Fork/Join) I discovered that the Perspective seems to behave buggy. I.e. afterwards I had a problem while Jacek solved his (by shaking the applications once or twice). Maybe you should tell EA to unplug the power if it won't behave correct

I also have only Save Changes, not Folder list. Now, David, what version do you (and maybe Jacek) use, that Jim am I don't have?

[«Midnight»]

I have build 788. Since (whenever, but probably 4.1) my Options / UML Toolbox dialog has had two lists of checkboxes. The LHS represents which panels appear in the toolbar, the RHS shows the possible buttons for the currently selected bar.

I have recently noticed (that is, it may have been this way for a while) that if you do not save the RHS - which you would not normally do if you had not changed the bars you want to see) then saving the buttons for a given bar seems not to stick.

I think these settings are specific to each technology - each one having its own set of buttons etc. I also suspect that the above behavior dates back to around 6.0 when technologies appeared in the 'default' UI.

[thomaskilian]

David,
I use the same build, but as mentioned the Toolbox does not change (for Fork/Join) whatever I try. I'd call this a bug but actually I don't care. Maybe someone at Sparx reads this and will have a look. I also had some issue with the visual layout which is somehow related to that. Same thing: I got it working somehow and don't care

[«Midnight»]

Bug report filed, referncing this and the Incomplete Toolbox threads.

There's something else wrong too, relating to how Perspective settings are saved and changed for projects, but I don't yet have a clear grip on that.

[davisford]

Hi, hidden buttons aside, if you're just looking to communicate something in an activity diagram, the control/object flow are visually the same in EA.  sure, the underlying db may label them as different objects, and the semantics in uml are slightly different, but if they are visually indistinguishable, what's the point?

[KP]

Hi, hidden buttons aside, if you're just looking to communicate something in an activity diagram, the control/object flow are visually the same in EA.  sure, the underlying db may label them as different objects, and the semantics in uml are slightly different, but if they are visually indistinguishable, what's the point?

I totally agree with you: From memory, UML 1 used a dashed line for object flows but changed to solid in UML 2. I have no idea why they replaced an unambiguous notation with an ambiguous one.

[sargasso]

Hi, hidden buttons aside, if you're just looking to communicate something in an activity diagram, the control/object flow are visually the same in EA.  sure, the underlying db may label them as different objects, and the semantics in uml are slightly different, but if they are visually indistinguishable, what's the point?

The point is...

If you are just doing the normal human thing and trying to explore the flow of information around a system then there really is no difference.  So why show them as different to a group of people who will then focus enitrely on the philosophical reason for the existance of  different flow types rather than the real problem of analysing, specifying or designing a system.

If on the other hand you are 99 levels deep in trying to understand the true semantic of the information flows within a system, then the difference becomes significant.  Then we get into the world of tokens and the rules that apply at the ends of the flows.  

The activation rule for a particular activity node may be, say, the presence of a token on a single, mutiple, selected or all or specified subsets of the entire set of input flows to the node.  The activation itself may be an invocation, interuption, disruption or even destruction of the activity node.

OTOH the presence of the token on an object flow quite often does not convey any semantic about node activation.
For example, the presence of an invoice from the gas company in my letterbox may or may not invoke any action on my part at all.  The presence of a token on the control flow from the  event: "final date for payment before we cut off supply has arrived" may invoke some type of (re)action.

bruce

[jeshaw2]

but if they are visually indistinguishable, what's the point?

But they are visually distinguishable; at least in terms of their routing rules on a diagram, but especially if you use colored Petri nets as the basis of your activity diagramming.  (The flow edges may be of a different color.)

Control flow edges connect directly to activity nodes and tokens flowing on this edge do not contain data values (yet).  

Object flow edges connect to object nodes which are inputs and outputs of activity nodes.  Tokens flowing on this edge do carry data.

UML tools need to enforce both the semantic and diagramming rules of these edges, no matter what level of abstraction.  EA enforces this rule by automatically providing the object nodes when the object flow is drawn and it disallows control flows to object nodes.

My clients don't have any trouble understanding the difference between, let's say, having the specifications for a part's manufacturing activity and an authorization to proceed with that manufacturing activity.  The source of product specification is different than the source of the authorization to produce; and the tokens had better come from the proper source or one ends up with an unwanted camel instead of a horse 'in the money'.  Users need to be able to verify correct routing of these different flows.  If they can not do this, you are not intervewing the proper stakeholders of the system.