Main Idea: To convert an activity diagram into a sequence diagram.
Problem: I want that if "Action 2" fails then, in that case all the flows get triggered again from "Action 1".
(i.e Action 1 --> Action 2 --> then the verification again. and this should happen until Action 2 is Successful)
Basically, the flow works like a GOTO function and then from there triggers all the steps again.
I have tried to use a ref block but again it seems that it might be ambiguous and someone might read it only as the "execution of Action 1" and not the steps after it.
Therefore I wanted some hints to make this sort of scenario clear. Any suggestions would be appreciated.
Attaching the image for better clarity of the problem.
The activity and sequence diagrams are not supposed to be equivalent. Both set a different focus (flow vs interactions) and as a consequence you might have to do the mapping by identifying higher-level constructs.
Here you have clearly a loop:
You could reformulate in pseudocode as: REPEAT action 1 and action 2 UNTIL action 2 passes, which is a loop that has the test in the end. You could further rewrite this loop into: Last did not passed; WHILE last did not pass, DO action 1 and action 2, or WHILE true DO action 1 and action 2 and BREAk if it succeeds.
Now you can use a loop fragment to achieve this behavior in a sequence diagram. This fragment would enclose action1, action 2, and the test for success, and after the loop, would come the interaction for the success case. The nesting makes it very explicit what gets repeated and what not. For example, some variant of:
Related
I have a UML book and I am reading about nested fragments. It shows an example of a nested fragment. But what I dont get.. why does it say "If the condition "cancelation not sucessful" is true when entering this fragment (i.e. cancelation was unsuccesful) the interaction within this fragment is no longer executed".
What I have learned before is that a condition should be true before the interaction will be executed? But in this case it says the opposite of it.. (because they say it should be false to execute the interaction)
See for the image: https://ibb.co/CmstLcX
I think this is simply a typo in the book. The diagram makes sense, but the text describes nonsense. While the condition is true, the messages in the loop will happen up to three times.
Maybe the author got confused, because the message immediately before the loop is Cancellation. I assume the loop guard is referring to the success of the Order cancellation message, not to this Cancellation.
By the way, reply messages need to have the name of the original message. Most people get this wrong (and some textbooks). I'll grant that the text on the reply message is often meant to be the return value. As such it should be separated with a colon from the name of the message. In your case it is probably not necessary to repeat the message name, even though techically required. However, the colon is mandatory.
If it is the return value, all reply messages in the loops return the value Acceptance. I wonder, how the guard can then evaluate to true after the first time. Maybe it is only showing the scenario for this case. This is perfectly Ok. A sequence diagram almost never shows all possible scenarios. However, then the loop doesn't make sense. I guess the author didn't mean to return a specific value.
Or maybe it is the assignment target. In this case, it should look like this: Acceptance=Order Cancellation. Then the Acceptance attribute of the Dispatcher Workstation would be filled with whatever gets returned by the Order Cancellation message. Of course, then I would expect this attribute to be used in the guard, like this [not Acceptance].
A third possiblity is, that the author didn't mean synchroneous communication and just wanted to send signals. The Acceptance Signal could well contain an attribute Cancellation not successful. Then of course, no filled arrows and no dashed lines.
I can even think of a fourth possibility. Maybe the author wanted to show the name of an out parameter of the called operation. But this would officially look like this: Order Cancellation(Acceptance). Again the name of the message could be omitted, but the round brackets are needed to make the intention clear.
I think the diagram leaves a lot more questions open than you asked.
It only says "If the cancellation was not successful then" (do exception handling). This is pretty straight forward. if not false is the same as if true. Since it is within a Break fragment, this will be performed (with what ever is inside) and as a result will break the fragment where it is contained (usually some loop). Having a break just stand alone seems a bit odd (not to say wrong).
UML 2.5 p. 581:
17.6.3.9 Break
The interactionOperator break designates that the CombinedFragment represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing InteractionFragment. A break operator with a guard is chosen when the guard is true and the rest of the enclosing Interaction Fragment is ignored. When the guard of the break operand is false, the break operand is ignored and the rest of the enclosing InteractionFragment is chosen. The choice between a break operand without a guard and the rest of the enclosing InteractionFragment is done non-deterministically.
A CombinedFragment with interactionOperator break should cover all Lifelines of the enclosing InteractionFragment.
Except for that: you should not take fragments too serious. Graphical programming is nonsense. You make only spare use of any such constructs and only if they help understanding certain behavior. Do not get tempted to re-document existing code this way. Code is much more dense and better to read. YMMV
I want to show use of same algorithm as a black box in two-pass iteration. In first pass, I would pass a value of a flag f as false, and an array of one element as A[1..1], output of first pass would be B[1..N]. In second pass, same algorithm would be used with f as true (to indicate second pass) with an input of A[1..N] (fed from output B[1..N] of first pass) whereas the output of second pass would be B[1..M]
Please help me drawing the UML Activity diagram for the same.
It's not a good idea to try "programming graphically". The algorithm you describe is better shown in meta code than in an activity diagram, as you already have seen. So what I'd do in your case is to have a single Action (representing most likely some CallOperation of some class. And the according behavior of the operation contains the description in either meta code or plain text (as you already stated above).
If for what reason ever you really want to "program graphically" you would need to use single actions for the assignments of the flag like this:
The A and B arrays would be just mentioned in the description of the single actions.
To actually show passing the A and B arrays you would need to add ActionsPins or Objects with ObjectFlows between the single Actions. Honestly, that would make the whole thing even more unreadable and hinder more than helping the reader:
In a UML Sequence Diagram - If a flow should stop if a condition is met midway, how would it be best represented with alternate / optional fragments?
i.e. -
If the stop condition is not met then the flow is continued for several more steps.
Should the alternate fragment cover all of the steps since the stop condition, making all steps past it part of the alternate fragment, or is there a notation to handle the stop inside a small alternate fragment (confined only to the condition)?
There are three options for this situation. Each of them I illustrate with a diagram showing how the respective combined fragment should be used. The actual behaviour is hidden with interaction references (normalFlow for a flow that should normally be executed and breakFlow for any flow that should happen in case of a required break).
The first solution is the most convenient one - it exactly covers your case and you can also use the positive version of a break guard. However each of them provide you a valid possibility.
Break combined fragment
When a break combined fragment is met and its guard condition is true, only this fragment is still executed and then the execution of the interaction (flow) stops. If the condition is not met, the combined fragment is omitted and the normal flow continues. This is exactly the case you describe. In this case you would put the messages that shouldn't be executed in case of a break condition after the break combined fragment.
Opt combined fragment
When an opt combined fragment is met it executes only if a guard condition is true. The rest of a flow continues regardless of the condition.
You can put the part of the flow that is continued only if the break condition is not met inside the opt combined fragment. The opt fragment should have a guard that is opposite to the condition at which the flow should stop. If any additional actions should happen in case of a break, they should be put after the opt combined fragment.
Alt combined fragment
When an alt combined fragment is met its guard conditions are evaluated and only the eventual one fragment which guard evaluates to true is executed. There might be also a situation when none of the guards evaluate to true and no fragment is executed in such case. Whatever flow is after the combined fragment is executed normally anyway.
In this case you would preferably put two fragments, one with the correct operation guard and the second one with a condition that should cause a break. Put the normal flow in the first fragment and whatever should happen in case of a break in the second fragment.
You could shortcut the whole thing by using an opt fragment:
One could start arguing that this is syntactically incorrect, but it transports the message (I guess). And that is what counts.
From my personal experience: use fragments as few as possible. Rather split your scenarios to focus on the certain important aspects. A SD is a snapshot of the system at a place where you want an overview over what's going on and not a detailed roadmap with each possible cat and dog trail.
I want to create a UML sequence diagram (see below) where I have an alt frame with two conditions (status equals foo or bar). In the foo case I send a synchronous message from A to B, get the return message and then proceed with the rest of the sequence diagram (call spam()). In the bar case I send another synchronous message from A to C to but there will be no return. I'm trying to model a function call in SW which doesn't return (it blocks forever on a semaphore) so in that case I will never proceed to spam(). Can this be expressed in a sequence diagram? I can exclude the return value but that would only tell me that there is no return value, not that there is no return at all. Can this only be expressed by splitting the diagram in two and handle the conditions separately or is there a better diagram to express this?
You can place a duration constraint between the call and the return.
Under normal circumstances, such a constraint would be represented by an integer followed by a time unit, such as "10 seconds" or by a range such as "[1;10) seconds".
Your question is interesting in that you want to model infinity.
I would go about doing it like this:
However I must admit that I am unsure if my formulation violates OMG's UML 2.5 standard. I did not find anything in the standard which explicitly disallows using 'infinity' as a time unit; the standard does mention that the time should be relative.
I'm creating a sequence diagram, and one of the classes is being observed by another class. The observed class is calling update in the observer every 5 seconds in a loop. I need to show this in the sequence diagram. Is there a way to show it looping indefinitely out of sequence as it were?
Or does it not make sense in the context of a sequence diagram; should I not include it? Or should I include it in a different type of diagram?
You can use a box enclosing the message send arrow (and whatever else is inside the same repetitive construct).
See this tutorial for an example.
link to larger image (archived)
Just adding a clearer picture because this one at #joel.tony's answer is damn blur.
As you can see the loop happens inside the frame called loop n. There is a guard, array_size, which controls the loop's iterations.
In conclusion the sequence of the messages inside the loop n frame (those between DataControl and DataSource objects) will happen array_size times.