Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: HenryStock on March 16, 2006, 08:47:11 pm
-
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?
-
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.
-
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.
-
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
-
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! ;D 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?
-
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?
-
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?
-
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
-
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.
-
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
-
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
-
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
-
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.
-
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
-
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
-
Is solves the sequentiality delemma, but it still is poor object oriented design strategy (per my reasons stated in my prior post) unless, of course, the flow from B to C is a control flow and not a data flow.
-
Granted!
(http://sargasso.sphosting.com/ActivitySynch.PNG) if the diagram ^ is invisible try http://sargasso.sphosting.com/ActivitySynch.html
-
Whoa Bruce,
I thought that activities have OR'd input tokens and joins have AND'd input tokens. That is, though some may not prefer the style of not using decision and merge symbols,
| A-----g1------>B-----> | D |
| | | ^ |
| | | | |
| +-----g2------>C------ | + |
is acceptable. g1 and g2 are guards. D does not activate unless flow is passed along via B OR C.
Also, I thought that it is bad form to have unbalanced fork/joins as in your diagram...
Jim, I think that I get your point. Is it diagrammed as this:
| A--> | ||------>B-----> | ||---->C |
| || | || |
| ||-------------> | || |
where: the join has a control flow input from B, an object flow input from A and an object flow output. This is at least consistent with my understanding of AND and OR applied to joins and activities, respectively.
My notion of forks implies concurrent threads of execution, and the above seems to have what I would call a "vacuous thread". Is there a tidier way?
Following some of the other threads about activity diagrams, I find that object flows are information about the object and not the object itself. In programming parlance I would say "pointer flow" or "reference flow". As such, is it really mis-leading to simplify to:
A----->B----->C------>
where all flows are object?
I find that some of the finer points of activity diagrams are not well described anywhere. Is there an authoritative text on the subject?
-
Woe me,
According to the UML 2.0 spec, an action must have all inputs satisfied before being executed. The only ORing node is the merge node.
This means that my last post was out to lunch. I can live with these rules, but I cannot reconcile examples that I've seen on the web that apparently use a different set of rules.
here's an example
http://www.agilemodeling.com/style/activityDiagram.htm
The "Enroll in University" action has three inputs, of which only one can be active at a time.
Is it wabbit season or is it duck season?
-
Woe me,
According to the UML 2.0 spec, an action must have all inputs satisfied before being executed. The only ORing node is the merge node.
This means that my last post was out to lunch. I can live with these rules, but I cannot reconcile examples that I've seen on the web that apparently use a different set of rules.
here's an example
http://www.agilemodeling.com/style/activityDiagram.htm
The "Enroll in University" action has three inputs, of which only one can be active at a time.
Is it wabbit season or is it duck season?
HI Steve,
You do need to distinguish between Activities and Actions - They aren't the same thing. Also you need to be able to determine if the diagrams you see are UML 1 or UML 2 (typically they will be UML 1). And finally (although this is mostly NOT true of Scott Ambler) many web based UML diagrams are like most stuff on the net - quality unguaranteed.
HTH,
Paolo
-
I think the Agile diagram is based on UML 1. UML 1 used state/transition thinking as the underlying metaphor and extended it into object flows in activity diagramming. UML 2 uses Petri Nets as the underlying science; a big change.
-
Following some of the other threads about activity diagrams, I find that object flows are information about the object and not the object itself. In programming parlance I would say "pointer flow" or "reference flow". As such, is it really mis-leading to simplify to:
A----->B----->C------>
where all flows are object?
Your point in red is not defensible.
You are thinking at the Programming level or at the Platform Specific level at least. At the Business Level, or the CIM level of modeling (where activity diagrams find their genisis), the data objects flow directly (by this I mean not by a reference to them). In a manufacturing activity for example: a shop order (data object) consists of a blueprint, a routing, and detailed specifications for each step in the routing. This is a physical packet, typically in a plastic pouch. Arrival of this pouch at a workstation on the shop floor is not authorization to proceed, even if the raw material needed is also present. The authorization to proceed is received from the dispatcher's execution of the shop schedule (which is a control object).
-
received from the dispatcher's execution of the shop schedule
Or a control event (represented as a flow in the current context, of course) as the case may be. The flows are what we're talking about here, and the receipt, resulting from the execution is the control. Your example of the packet being an object flow is exquisite. [I'd expect nothing less...]
-
Thanks midnight.
Thinking about the packet, I'm wondering if I've just discovered something new here? Would that be a UML Package thats flowing instead of a data object? ;D
-
Be careful here! If the delivery directions for these things are in one of the associated documents then you may have just invented Package Switched Networks. This could be the dawn of a new dark age... :o
-
I think the Agile diagram is based on UML 1. UML 1 used state/transition thinking as the underlying metaphor and extended it into object flows in activity diagramming. UML 2 uses Petri Nets as the underlying science; a big change.
I gave that example because I have an Ambler book "Elements of UML 2.0 Style" with the same diagram. I guess the 2.0 revision used an old diagram that was not scrutinized...
I am sorry to seem obtuse, but I am still fuzzy about the use of object flows. Any examples that I have found either in text books or on the net seem trivial.
A simple real example that I am working on:
I have a read action: int wRead(void *pData, int nMaxBytes).
I have a class CMsg. It was attributes of a header structure and a pointer to the message payload.
The read is first invoked to read in a message header. The header contains the length of the payload, which is used to allocate memory for the playload and as a parameter for the second read. I am trying to capture the activity with control and object flow.
In the activity diagram, I have object flow from the first read to a CMsg object. Does the read have a "pData" action pin? Does the CMsg have a "sHeader" port?
When the header is set in CMsg, it allocates memory for the payload. Do I show the allocation on the activity diagram? If so where?
I have a data store object for the payload. I would not ordinarily model the data store on the static class diagram. It magically appears on the activity diagram. Do I care?
For the second read, where does object flow? It makes sense to me for it to flow to a data store object. Same question about action pins and ports.
When the message has been handled, do I show deallocation of the payload memory?
Am I getting close?