• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Activity Diagram--Activity vs. Decision Diamond

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello fellow Moosers!

The following is a seemingly long post, but very simple to follow. I promise

I'd like to use an Activity diagram to model a certain method in my application. The application gets a hierarchy of interleaved entities--TypeA and TypeB--from a database, based on an initial selection. For example, if a TypeB entity was selected, then the next highest entity would be TypeA, and so forth.

The returned list might look like this:

TypeA
TypeB
TypeA
TypeB
TypeA
TypeB (this was the originally selected entity; it started the upward search)

Simple enough, eh? A simplified description of the method looks like this:




Ok, I used to model these things with my own self-styled flow diagrams. It was easy because I used diamonds to indicate decisions and starts of loops, and then I added some text to explain trips to the database, etc.

Activity diagrams are different in that they include both decision diamonds and activities. I find it hard to know when to use each. For example, should I name �Determine if TypeA or TypeB� as an activtiy or should it actually be a decision diamond?

Since I can't find any Activity diagrams on the net, that pertain to computer algorithms, I've been using this example...

http://etna.int-evry.fr/COURS/UML/notation/notation10.html

...which also confounds me a bit. For example, why isn't the activity �Find Beverage� a decision diamond instead? And why isn't the �no cola/found cola� decision diamond an activity?

Any smart guys out there who can shed some light on this?

Thanks in advance!
Kristian
[ May 30, 2006: Message edited by: Kristian Kringleheimer ]
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There seem to be several problems lurking in here.

The first is that, despite the visual similarities, a UML activity diagram is not quite the same thing as a traditional flowchart. As it mentions on that page, an activity diagram has aspects of a state diagram.

In a traditional flowchart, it is relatively aasy to tell the difference between processing (rectangles) and decisions (diamonds). The rule of thumb I use is that a decision diamond must not include any input, output, processing or calculations. All the information it needs to make its decision must already be present. This is why you often see a rectangle labelled something like "work out stock levels" immediately before a diamond labelled something like "stock level below reorder threshold?"

In an activity diagram this distinction is not necessarily so clear. The "state diagram" nature implies that each "box" represents a point at which the flow might stop for a while. Such stopping points can be user options (e.g. pour coffee), long-running processes (e.g. brew coffee), input and output etc.

From this point of view, the "find beverage" activity is shown as a box, because it potentially takes time. The confusion comes because the author of that diagram has chosen to have two state-change outputs (coffee & no-coffee), followed by a subsidiary decision (cola & no-cola) rather than just providing three state-change outputs from the original activity (coffee, cola, nothing). I assume this is done to make the decision process more transparent - to show that the coffee/no-coffee decision has a "higher priority" and thus resolve the case where both coffee and cola are available, which would be unclear in the three-output version.

The bottom line (as with all UML diagrams, really) is that you need to consider the reader and what information they need, so that you can make sure that this information is clear in the diagrams you produce.
 
Kristian Kringleheimer
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank Frank--that was a really good explanation. I reworked some of my diagrams and, iterestingly, I didn't have to change very much. So either I've been drawing Activity diagrams all along and mistakenly calling them Flow diagrams...or I just redrew my Flow diagrams and am now calling them Activity diagrams.

In any case, they're pretty close. But that might be the nature of my algoriths.

Thanks again!

Kristian
 
reply
    Bookmark Topic Watch Topic
  • New Topic