AD: Guards and Decisions

[Paolo F Cantoni]

Under UML 1.x, I often used to have control flows coming directly out of (the equivalent of UML2 Activities) with appropriate guard conditions on them.  Thus I was able to dispense with the decision node.

Depending on the tool, you were allowed either only one inbound flow or more than one, only one or more than one outbound flow.

EA allows multiple inbound and multiple outbound control flows to an activity.  If each outbound guard is correctly constructed so that the model is well-formed (see OMG UML Specification section in the EA "Activity" help topic).  Then it aught to be OK?  Yes?

However, reading the UML 2 specification, I distinctly get the impression (more so than UML 1.x), that OMG want you to use the Decision node to do the alternate flow processing.  I say impression, because I can't find any definitive statement to that effect.

Comments or thoughts anyone?

Paolo

[mikewhit]

My only thought is that it is possibly closer to 'programming' to write sequential decisions, than to construct well-formed (i.e. non-overlapping, with always a defined outcome) guard conditions, which have more in common with state transtion diagrams.

Cf.Activities may describe procedural computation - in which case, explicitly writing out the decisions sequentially gives a closer mapping to how the process will eventually be implemented.

If the decisions are described by guards, it might be possible to translate the decision-making process in such a way that it did not literally correspond to the model, because many (most?) implementation languages do not support the construct of N-way predicate-guarded flows of control.

If that makes sense to you ...

[Paolo F Cantoni]

Hi Mike,

My only thought is that it is possibly closer to 'programming' to write sequential decisions, than to construct well-formed (i.e. non-overlapping, with always a defined outcome) guard conditions, which have more in common with state transtion diagrams.

On first encounter that might seem to be the case, but I'm not so sure...

Cf.Activities may describe procedural computation - in which case, explicitly writing out the decisions sequentially gives a closer mapping to how the process will eventually be implemented.

Why is that? (see below)

If the decisions are described by guards, it might be possible to translate the decision-making process in such a way that it did not literally correspond to the model, because many (most?) implementation languages do not support the construct of N-way predicate-guarded flows of control.

Agreed, I think.  Could you provide an example of this variant translation?
However, there is NO provision in UML to explicitly place the (say) If condition in the Decision node.  You can only do it by implication in the guards associated with the outflows (as far as I can tell).  
So, I don't really see any practical difference (at this stage).  And, in fact, it was that line of reasoning that got me into the "use guards directly" mode in the first place.

If that makes sense to you ...

Sure does!  Thanks for the input!   Any further thoughts?

Paolo

[fwoolz]

Hello All,

FYI--The UML 2.0 Reference by "Los Tres Amigos" says the following:

"A decision node has one input and two or more outputs." (pg. 305) Figure 14-111 on the next page shows a decision node with three outputs (>0, <0, else) ala' if-elseif-else.

Additionally, the same book shows an example (Figure 14-283, pg. 661) showing the use of junction pseudo-states (filled circle) with guarded transitions as an alternative to decition nodes.

In a word (well, actually 8 words, one of which is a contraction)  TMTOWTDI.



Cheers,
Fred Woolsey

[fwoolz]

One more thing...

As a matter of style, I would use different exit points for multiple transitions from a state node, perhaps with post-conditions attached to each describing the corresponding condition (although this might be redundant if the condition is made clear by the transition guard expression).

Cheers,

[alexander]

I think that we should not loose sight of UML's purposse.
Although it allows for a lot of possible representations for the same sequence of activities, the purposse is to transfer in an unequivoque way the business 'knowledge' to an engineering language.

With that in mind we limit what you can do with UML to a subset of patterns.

In this particular case, we only allow multiple control flows to enter or exit an activity if it is used to handle exceptions in wich case we use the 'interruption flow'. Any other control flow should be sincronized (either synchronously -join- or asynchronously -decision-) before entering the activity.

In any way, UML allows for a lot of workarounds, you should decide if your diagram is clearly transmitting what you want to say... just a thought

[mikewhit]

Additionally, the same book shows an example (Figure 14-283, pg. 661) showing the use of junction pseudo-states (filled circle) with guarded transitions as an alternative to decision nodes.

All I can say is - be careful when looking at Junction & Choice nodes - http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1102602113

[fwoolz]

Mike,

Thanks for the caveat. I would suggest, however, that such concerns are, IMHO, important only if you are building an executable model or are generating code directly from a statechart or activity diagram.

One thing that I have done when using UML diagrams to convey the design details to others (clients, programmers)
and to keep from forgetting exactly what I meant when I put a diagram together is to build a "graphical glossary." By that I mean a package of diagrams, with explanatory notes, showing the constructs used in the actual model and how they are to be understood. I found this to be particularly useful for projects stretching out over any period of time, since memories need refreshing from time to time.

[Paolo F Cantoni]

Mike,

Thanks for the caveat. I would suggest, however, that such concerns are, IMHO, important only if you are building an executable model or are generating code directly from a statechart or activity diagram.

One thing that I have done when using UML diagrams to convey the design details to others (clients, programmers) and to keep from forgetting exactly what I meant when I put a diagram together is to build a "graphical glossary." By that I mean a package of diagrams, with explanatory notes, showing the constructs used in the actual model and how they are to be understood. I found this to be particularly useful for projects stretching out over any period of time, since memories need refreshing from time to time.

I'm with you Fred.  I have created a "Modelling in a Nutshell" document which I used to hand out during modelling sessions and to people who needed to "appreciate" the models.  Unfortunately, it's oriented toward Data Modelling using some personal extensions to the standard? Entity-Relationship modelling approach.  Hardly anyone read it (who reads user manuals?), but it was still necessary to produce and as you imply, the important point was to keep oneself and others on the "straight and narrow".

Paolo

[Paolo F Cantoni]

Hi Alexander,

I think that we should not loose sight of UML's
purpose. Although it allows for a lot of possible
representations for the same sequence of activities, the
purpose is to transfer in an unequivocal way the business
'knowledge' to an engineering language.

The OMG states:

The OMG's Unified Modeling Language™
(UML®) helps you specify, visualize, and document models of
software systems, including their structure and design, in a way
that meets all of these requirements. (You can use UML for
business modeling and modeling of other non-software systems
too.)

So software modeling, is just one of its uses, albeit the
primary one.

With that in mind we limit what you can do with UML to a
subset of patterns.

This is a good move... Patterns are extremely useful.  But which
subset, and in which context and what forces?

In this particular case, we only allow multiple control
flows to enter or exit an activity if it is used to handle
exceptions in which case we use the 'interruption flow'. Any
other control flow should be synchronised (either synchronously
-join- or asynchronously -decision-) before entering the
activity.

Why?  As I hinted in my original post, I got the distinct
impression that this was the case, but I couldn't find any
explicit direction to that effect in the OMG specifications.

Everything said so far about decision or merge nodes appears to
apply equally well to the activity itself (if I've understood
things correctly).

Since, at present, code engineering doesn't touch activity
diagrams, and...

(Self) However, there is NO provision in UML
to explicitly place the (say) If condition in the Decision node.
You can only do it by implication in the guards associated with
the outflows (as far as I can tell). ).

I don't really see
any practical difference (at this stage).

In any way, UML allows for a lot of workarounds, you
should decide if your diagram is clearly transmitting what you
want to say... just a thought

Good thought!  But my question still applies...

Paolo

[alexander]

About the patterns subsets and context, in every proyect (we use a UP approach) we have an standards artifact that addresses this, so in the whole project we have the same patterns, for example, for test description we will use this pattern, for design of this 'stereotype' analysis class we will use this pattern, for grouping of subsistems we will use this or that pattern.
Much of the realizing on which case you can apply which pattern is done by the functional arquitect (a higher profiled analist with extensive experience in design and patterns), so, as you pointed out, the key is the context of the pattern but the result is the uniformity of design pieces by different analysis units and the ability to read any model by understanding the patterns used in the project.

In regards to the desicion, merge issue, when using direct flow control in the activity you loose sight of the sinchronisation context of the flows: when splitting with a fork you have multiple sinchronic flows which must be re-sinchronized before continuing merged so we use a fork-join structure, when splitting with a desicion you have one active flow that has to decide on which path it should travel so when all paths merge they should do so in an asynchrony way using a merge (or inverse decision) element.
I agree it can be deduced which type of synchronization should be used by taking a look at the point where the flow splited, but in a large diagram with desicions and forks it can be pretty confusing.
Interruptions are a different case since they are treated like exceptions to the natural flow of the program so we also allow an exception to the rule here.

The quote about the guards wasn't mine so i won't answere it...

I hoped this last part has answered your question...

[Paolo F Cantoni]

[SNIP]
I agree it can be deduced which type of synchronization should be used by taking a look at the point where the flow split, but in a large diagram with decisions and forks it can be pretty confusing.
Interruptions are a different case since they are treated like exceptions to the natural flow of the program so we also allow an exception to the rule here.
[SNIP]
I hoped this last part has answered your question...

Thanks Alexander, that has certainly helped me!  I agree that when you are dealing with synchronous/asynchronous issues the bar is required.  Further, in this case it may well be that Decision/Merge nodes are more useful...

Bruce and I (correct me, if I'm wrong Bruce) are discussing the purely synchronous case.  Particularly where one might be modelling domain related activities (such as business processes etc).

Paolo