Let's say I have a decision node. I want the output of that decision node to be the input of another decision node, without having to create another action in the middle. Is it possible to do that in UML?
In short
Yes, this is possible.
What does it mean?
There are two kind of flows in an activity diagram:
control flows: the arrow is more or less answering the question "what's next?".
object flows: the "what's next" is related to objects passed along the arrow.
The rule for a decision node, is that if the primary incoming edge is a control flow, all the outgoing edges shall be control flows. Conversely, if the primary incoming edge is an object flow, all the outgoing edges shall be object flows.
In this regard, it is important to keep in mind that a decision node is not an activity that creates an output; It just routes the incoming control flow tokens or objects to the right branch.
So you can definitively take the output of a first decision node as input for the second decision node. The only constraint is that the incoming flow of the second node is of the same kind as for the first node.
Related
I tried to reduce my problem to the following simple example. If the profit is low and the customer is not a regular one then the order should become canceled. In all other cases (low/regular, high/*) the order is to be executed. How should I model the disconnected part in the middle?
Wheter or not the client corresponding to order is a regular client follows from the data model:
I assume you are looking for the formally correct way to model this. Here it is:
If less formality is sufficient, you could skip the decision input flows and simply assume that the guards have access to any objects in the scope of the activity. Then one decision node is sufficient with a guard [profit=low AND not order.customer.regular Customer].
UML specs 2.5 says:
The effect of one ActivityNode on another is specified by the flow of
tokens over the ActivityEdges between the ActivityNodes.
But above definition is obscure; specially because tokens are not explicitly modeled in an Activity.
After reading 15.2.3.3 Activity Edges section of specifications, I think purpose of them is:
to capable the diagram to describe
it may wait for other token
or refuse flow
instead of entering next node immediately
Is it true? Also is it the only purpose of tokens? If it is true, why we do not use a decision node with a condition and a end flow node for showing refusing flow under that condition instead of token and guards? Or grouping information into larger objects node which carries all necessary data instead of using weight?
Activity diagrams and state machines are both derived from Petri nets. Giving a full description would blow this answer, so I try to boil it down.
A token is, so to say, a bit of information. It's atomic and can not be split. Rather it is created from a "big bang" out of an event which is defined in the context (shown usually by a large black dot). It travels along InformationFlow connectors (eventually blocked by guards where it has to wait) to nodes. Nodes have 1 to many InformationFlow connectors. A node becomes active when at all of its incoming InformationFlow connectors a token has arrived. When the node finalizes it sends single tokens along all its outgoing InformationFlow connectors (at least UML actions do so which is called implicit fork). There are special nodes like fork and merge which behave a bit different (see the specs). Finally tokens can fall in a sink (usually a circle with a fat dot inside) where they just vanish as they appeared.
So from a single token (not going to explain the details/issues of multiple start points here) emerging from a start node this token travels in the net, eventually creating other tokens all circulating until (usually) all tokens have gone to sinks. During that the net is said to be active.
tl;dr No, your assumption is not correct that way.
My question is about the merge node in the UML activity diagram, when and why to use it?
Merge node example:
A merge node accepts a single token to continue processing. Other nodes need tokens at all incoming edges to start processing. So if a flow is split by a decision you have a single token passing at one side of it. In order to reach the Join at the lower end, you need to collect either flow left and right to collect the single token and pass it on.
N.B.: Activity diagrams have their root in Petri nets. You could consult Wikipedia to see how they work in detail. There also a couple of answers here on SO.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
I have the below UML activity diagram for a shopping cart use case. It has several decision and fork nodes but there are no corresponding join/merge nodes. Could you please show me:
how to correct the diagram by introducing the merge/join nodes.
how to modify the diagram so that a customer can repeat the process (of adding more products to the shopping cart).
Thank you.
You should look into the token concept. It is introduced in petri nets and also used in the UML activity diagram.
Decision nodes produce one token only, i.e. they follow just one outgoing path. To merge such paths, of which only was is followed, you can use a merge node. Which just looks like a reversed decision node and is able to consume exactly one token. A diamond with multiple incoming edges.
If you use a parallelization node to start concurrent execution paths, you have multiple tokens leaving the parallelization node. To merge these kind of paths, you can use a synchronization node, it looks like a reversed parallelization node and has to consume one token per incoming edge.
(source: amg at www.lcc.uma.es)
Do you have an initial activity element anywhere? Makes it a bit easier to read. To your question, the merge should be used as opposed to having multiple connectors coming into the same activity. For instance, "Acknowledge Msg" should have a merge above it that the other branches can flow into.
As for how to make it repeatable, you may want an "Add to Cart" action, and prior to a "Checkout" action, have a Decision with guards for "Shopping Complete" (which goes to the Checkout action) and "Continue Shopping" (which goes back to "Enter Product #").