Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: jeshaw2 on March 18, 2006, 07:15:23 pm
-
I've figured out how to add an Object Flow line on an activity diagram, but how does one add a Control Flow line?
-
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.
-
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
-
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
-
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... ;)
-
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
-
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?
-
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 ;D
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?
-
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.
-
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 :P
-
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.
-
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?
-
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.
-
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
-
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.
-
Jim's points are well taken. If you don't need to differentiate between the flow types, it is likely that you don't need to see a visual difference (at least at this level of abstraction). When you do need to see the difference, the object nodes are there to make this evident; they can also carry additional information that the model can display or query.
Outside of the systems world, I was using EA to model some business processes a while ago (v. 4.1). We needed some means of quickly and simply conveying our understanding of processes to a management community while the processes being finalized. This would allow corrections in the processes as well as helping determine which parts of the processes could be supported by automation. The business processes were unique, involving negotiation between several parties towards a positive end, where previous dealings tended to be settled through legislation and the courts.
By using activity diagrams like flow charts we were able to illustrate the overall processes. Our clients could quickly make sense of things and identify errors. So far so good, and down to the next level. We used swim lanes to show the 'who' dimension and let the activities talk about the 'what.'
By adding object flows we could differentiate between "then we do..." events (the control flows) and "the initialled draft goes to..." transitions (the object flows). The clients, who had no experience with UML were able to quickly pick this up. We initially included notes tied to the object nodes to explain what was happening. Before we could provide a short document to explain the notation they suggested that we remove the notes and forego the help document, as they felt they could clearly see what was happening and understand what was going where (object flow), as well as see the flow of activity supporting the protocols and negotiations (control flow). [Interesting enough, with early experiments using dotted arrows the users complained that the different visual cues were confusing; they were reluctant to continue with that experiment even with a user guide.]
Worked like a charm, even outside of the systems world. When the level of abstraction was low enough that people needed to see the difference the notation is effective. At a higher level it probably won't matter.
Of course these days we might well use BPMN. That was not an option with EA back then. However, my feeling is that at the level of abstraction we were talking about, UML activitiy diagrams did an excellent job, particularly by separating control and object flows. I also think we'd still be giving courses on pi calculus to managers, executives and lawyers to explain how to read the BPMN models, probably using UML activity diagrams as props.
-
Hi Jim, I have to disagree. The fact that the tool may/may not enforce the drawing of one line that looks the same as another between two elements is not visually distinguishable for me, and provides no concrete semantics when reading the diagram. This problem is exacerbated by the fact that activities and actions are dangerously close to looking the same. Last time I tried to use this in EA, the object port/node did not automatically fill in; my question was more specific to that scenario. Even in the case that you're modeling formal petri nets, if the arrows provide no visual distinction, just the fact that an arrow goes from/to an object defines it as an object flow, and if it is to/from an activity to another activity, you have no way to know...well, now it appears you do with the object node/port. I still find it dangerously ambiguous and only those that are very familiar with the model syntax/semantics will get it. In my humble opinion, I find it a poorly defined part of the UML spec.
-
Everyone's points are well taken and I'm not feeling compelled to dispute any of those points. However...
The arrows on the old flow charts were control flows, not object flows. They showed the ordering of activities, not the flow of data. In the old days, data locations were static (e.g., COBOL's Working Storage Sectiion) they did not move. Now, data (in the form of objects) logically flow also.
The fact that data flows to a downstream node does not mean, a priori, that that activity will be the next activity to fire. At a fork, data references may go in two directions at the same time to different activities and the first of those to fire is indeterminate. You need control flows to spell that out.
If you user is not concerned about the order in which activities happen (such as the relative ordering of database record updates), well then, you don't need control flow arrows. If you user is not concerned about the sequence of data transformations that lead to a result, for example: a+b/c versus (a+b)/c, then you don't need the data object flows.
It all depends on the subject of discourse. I don't see this as a level of abstraction, but as a matter of subject selection.