Activity Diagrams

[HenryStock]

I am trying to evaluate enterprise architect right now and I am trying to do some simple diagrams.

Beginning with an Analysis Diagram.  My issue is that I can't  find some of the diagram artifacts that I think I should see in the toolbox...

For example when I look at help "Working with UML diagrams" under the Activity diagrams I see a "Recieve Symbol"  ... I don't see that symbol in the tool box anywhere that I can note.  The same goes for the send symbol and the event symbols, etc.

Some of these symbols are used in the Example project. I just don't know where they got them from.   ???If I can't find them in the tool box, how can I add them to the diagram?

What am I missing?

[Eve]

At the very top of the toolbox there is a combo box that allows you to select a perspective.  This effectively shows/hides parts of the toolbox.

If you set the perspective to 'All' or 'UML 2.0' you should get all the symbols you want.  The ones you have mentioned are in the 'Activity' folder

Finally, if that doesn't work, 'Tools' | 'Options' | 'UML Element Toolbox' allows you to manually specify what should appear.

[«Midnight»]

It's also worth noting that you can end up with more toolbar icons than your display can show. When this is the case, triangular scroll buttons appear in the 'bar' part of the toolbar above and below the icons. Use these to scroll until the ones you want come into view.

Even though I used Office toolbars for some time, the wealth of things happening in the EA UI caused me to miss these for the first few sessions.

[Guy Manning]

in the toolbox for Activity Diagrams, I can't spot a symbol for a WAIT state or time related activity..can anyone tell me where it is or if not how to sue thsta IS there to show an activity that has to wait for an event  etc.
Ta

[jeshaw2]

There may be several ways to approach this.  Here is how I do it:

I designate the Process element on the analysis diagram as being a composite.  In the underlying Activity diagram, I do the following:

Create a Join node and a Timer Object on the diagram.  Timer object may have a WaitTime property. Show a control flow from both the upstream activity and the Timer into the Join node.  Show a control flow from the Join node to the downstream activity.

The downstream activity may not initiate until it gets a control token from the Join node.  The control token may not leave the Join node until a token from each of the inputs has been received.  Timer emits its token at the end of the wait process.  Upstream activity emits its token when its process is complete.   Bitty-bing, Bitty-boom!    Don't use a Merge node for this.    Merge nodes don't perform synchronization.

An advantage of this approach over a Wait node (if there is such a beast) is that I may dynamically set the timer's WaitTime property with an object flow.  

Control nodes do not have attributes in which one may store wait time values.

Come to think of it, are synchronization issues important at the Analysis level of abstraction?  On an Analysis diagram, isn't synchronization just another process with two or more inputs?

[sbrooke]

I have an observation about activity and all other dynamic behaviour diagrams (except sequence). There seems to be a disconnect between these diagrams and the static (class) diagrams.

On a sequence diagram, when adding a message between instances of predefined classes, I get a pull down menu offering me the operations defined for the class. While my sequence diagram may not be directly testable (no code generation), I know that at least it is consistent with the class diagram (which is directly testable).

I think that the same thing should be available for other dynamic behaviour diagrams: an action in an activity diagram should map to an operation. On state diagrams, a state variable should map to an attribute and a state transition should map to an operation. Otherwise, the dynamic behaviour has no relationship with the class diagram.

Am I missing something?

[Bruno.Cossi]

Hi,

try dragging a Class Operation from Project View onto an Activity Diagram. It will automatically create a matching Action for you.

Hope this helps!
Bruno

I have an observation about activity and all other dynamic behaviour diagrams (except sequence). There seems to be a disconnect between these diagrams and the static (class) diagrams.

On a sequence diagram, when adding a message between instances of predefined classes, I get a pull down menu offering me the operations defined for the class. While my sequence diagram may not be directly testable (no code generation), I know that at least it is consistent with the class diagram (which is directly testable).

I think that the same thing should be available for other dynamic behaviour diagrams: an action in an activity diagram should map to an operation. On state diagrams, a state variable should map to an attribute and a state transition should map to an operation. Otherwise, the dynamic behaviour has no relationship with the class diagram.

Am I missing something?

[sbrooke]

Bruno, you rock!

Should I have been able to figure this out from the help/tutorial?

I've tried this with a state diagram. I can drag an attribute into a state, but I can't drag an operation into a transition.

Steve

[jeshaw2]

Hi,

try dragging a Class Operation from Project View onto an Activity Diagram. It will automatically create a matching Action for you.

Just out of curiosity, Is the activity element's notation thus developed (with the class reference) a UML 2 standard or is that an EA feature?  I don't remember earlier versions of UML supporting the class reference notation.  Also, I could not find a way to provide that notation directly from the element's properties menu.

[Bruno.Cossi]

Hi Steve,

to be honest, I have found this out by an accident :-) Not sure if this is described anywhere in the help, and if it is, then probably somewhere where you will find it only if you know that it is there and therefore not really need it :-) I think a book of "EA for Dummies" sort would be an instant bestseller...

Bruno

Bruno, you rock!

Should I have been able to figure this out from the help/tutorial?

I've tried this with a state diagram. I can drag an attribute into a state, but I can't drag an operation into a transition.

Steve

[sbrooke]

Right now I set the thickness to a heavy line for each object flow connection. Is there a way to do this for the entire diagram so that object flows have a different line type from control flow?

More importantly:

• Is there any need to graphically distinguish object flow from control flow?
  
• Do people mix control and object flow in the same diagram or use control flow with an object tag if required?
  

Steve

[«Midnight»]

To the best of my knowledge:

Sparx has recently answered why the two flows are hard to distinguish. The answer won't make you happy, but they're right; the UML 2.0 spec has tangled this up. Search the forum for recent discussion on object flows (I think this will find the thread).

Yes they can be used together, and there are reasons for doing so. I think it was Jim (sorry if I have this wrong) who was recently pointing out that there are several good ways of clarifying which is which, and EA can handle these well. Again, look for the recent threads.

In both cases there are references to the UML Superstructure. Note that in several cases this is the earlier one, so when you retrieve anything from OMG try to find earlier versions.

As to the rest, the other posters to this thread have it well in hand. There's little I could do that would improve what's been said.

David

[jeshaw2]

Here is one reason to diagram both control and object flows.  Consider an object flow from A to a fork node thence to B and C in parallel.  

An object token will flow from A to both B and C simultaneously.  Generally, arrival of the required data object is sufficient for an activity to start; thus, both B and C would execute concurrently.

However, if C is not to start until B has completed, a Control flow from A to B then to C is required to assure the sequential order of execution.  

It would not be good O-O form to eliminate the fork node and control flow having the object flow from A to B to C.  That would have the object token flow unchanged through B to C and make C unnecessarily dependent upon B and giving B an unnecessary piece of responsibility.

[«Midnight»]

And that, however subtle, shows the difference between what we model in UML and what we develop in COBOL 80.

Back when the pundits were telling us to decouple things this is the kind of thing they meant, but could not express. Shows you the limits of the language (programming or spoken) versus the semantics (UML or other).

Thanks Jim

[sargasso]

By definition, an activity cannot/does not initiate until the presence of tokens on all the incoming flows are detected.

So, in Jim's case :


A--->||----->B-------
                      ||                                                                                                        |
                           ||                                                                                                   v
                      ||------------>C

solves the sequentiality dilemma.

bruce