Activity Diagrams

[jeshaw2]

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.

[sargasso]

Granted!
 if the diagram ^ is invisible try http://sargasso.sphosting.com/ActivitySynch.html

[sbrooke]

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?

[sbrooke]

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?

[Paolo F Cantoni]

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

[jeshaw2]

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.

[jeshaw2]

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).

[«Midnight»]

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...]

[jeshaw2]

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?  

[«Midnight»]

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...  

[sbrooke]

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?