What is the difference between the alt and opt fragments in UML sequence diagrams?
alt is used to describe alternative scenarios of a workflow. Only one of the options will be executed.
opt is used to describe an optional step in the workflow.
For example, for an online shop purchase sequence diagram you may use opt to describe how the user can add gift wrapping if she wishes. alt may be used to describe two variants of payment: using credit card or wire money transfer.
In the UML specification the meaning is described in section 17.12.15. opt and alt are two different operator types and here's how the specification describes them:
alt:
The InteractionOperatorKind alt designates that the CombinedFragment represents a choice of behavior. At
most one of the operands will be chosen. The chosen operand must have an explicit or implicit guard
expression that evaluates to true at this point in the interaction. An implicit true guard is implied if the operand
has no guard.
opt:
The InteractionOperatorKind opt designates that the CombinedFragment represents a choice of behavior where
either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative
CombinedFragment where there is one operand with non-empty content and the second operand is empty.
Alt is alternative flow (SWITCH or if. IF with two paths) Opt is IF with one flow. If you use Opt, code will be executed or not !
UML - sequence diagram alt vs opt
alt - if else
opr - single condition
Alt (alternative) is indeed similar to "if" but neither is limited to 2 options only, both can actually have many "else", many options, as needed. For example: //if (a=b) then a++; else if (a>b) then a--; else b++. In any case, if Alt is part of a code that is being called, Alt will execute.
Whereas Opt (Optional) not necessarily will be executed even if it is contained in the middle of a sequence or code that is being called. Typically, to execute an Opt sequence requires external interaction from user that is making a decision where many options were presented (like choosing an online paying method). In this particular case, as opposed to an Alt sequence, if the paying methods were "credit card", "pay pal" or "prepaid", the code will have 3 Opt sequences - with only one flow each -, but one and only one of the Opt sequences will actually execute.
Hope this helps!!
Best,
SD
They are basically the same.
alt is more used for several choices, like a switch sentence group in C programming language. While opt is more used for only two choices, like a if sentence.
But, don't get surprised, if you see both concepts used interchangeably.
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
What is a UML fragment is using in a case representing a check operation that either stops the further execution on a failed check or lets it go, kind of a programming statement if role != 'admin': break:?
I found the assert fragment seems to fit the case.
The idea on a diagram:
Is the fragment used properly to represent that operation change_sensetive_settings() is executing only if a user has admin role?
I'm not a big fan of assert, which seems to be meant for visual procedureal programming rather than clean design of valid behavior. There is not much information on assert fragment in the standard:
The interactionOperator assert designates that the CombinedFragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace.
But the way assert is used here, seems confusing in this regard: you just show a constraint { user.role == 'admin } on the server lifeline, whereas the continuation will result in a message being initiated on the client side.
To disambiguate this diagram, I'd recommend to enclose in the assert fragment the sequence made of the register_user() message, followed by the return message and your constraint. This would clearly relate the outcome regarding the user role constraint to the registration.
But this only tells a part of the story. Because, what does it mean in pratice that "All other continuations result in an invalid trace" ? Assert, just tells an assumption. Is there anything ahead of this interaction that makes this assumption realistic? If not what should happen if the user has insufficient authorisations?
For all these reasons, I'd rather recommend to use here and alt to show the normal flow, but also suggest that if the user does not have the right authorisation, something should happen (and on which side: client or server).
No, I think assert is not used correctly. Here is why:
The specification defines:
The interactionOperator assert designates that the CombinedFragment
represents an assertion. The sequences of the operand of the assertion
are the only valid continuations. All other continuations result in an
invalid trace.
That means, the state invariant {user.role='admin'} is the only valid continuation after the reply to the register_user() message. This would rule out other outcomes. I don't think, this is what you had in mind.
So, simply remove the assert fragment. Since the sequence diagram only shows one possible scenario, it doesn't mean, that other scenarios are not valid. You could have another sequence diagram, where the state invariant is {user.role='student'}.
If you want to show more scenarios in one diagram, you could use an alt fragment. However, as others have pointed out, the purpose of the sequence diagram is not visual programming. Therefore, striving for a complete description of all possible scenarios is not appropriate.
minor mistakes
There are some minor mistakes in the diagram. Most of them have been pointed out by others, but to make this a complete answer:
The first message could be a found message. Then the circle would be filled and the name of the message would be on the arrow. It could also come from a gate. This would be shown by originating the arrow from the frame. I would recommend the latter.
The state invariant should probably move down below the reception of change_sensitive_settings because the user could still try to change them. Only the server can decide to reject this request. Or it must move to the client lifeline, if you want to specify that the client only sends the message, if s/he is an admin.
The arrow at the end of the diagram should be dashed, since it is the reply to the synchronuous message it begins with. And again, it should end in a black circle denoting a lost message or, better, at the frame of the diagram.
We are learning in school that behavioral State diagram's transition has syntax:
list of events [guard condition] / list of actions
But I couldn't find any example on Internet where is used transition with multiple events. Is it really possible? If yes, how does it behave? Does it mean that transaction is realized when one of this events occurs (and of course condition is fulfilled)?
Yes, a transition can be triggered by one of many events in a list. You would use such a construct to avoid multiple lines between states, making a tidier diagram.
Here is what the 2.5 spec says:
14.2.3.9.2 Enabled Transitions
A Transition is enabled if and only if:
[ . . . ]
At least one of the triggers of the Transition has an Event that is matched by the Event type of the dispatched Event occurrence.
These logically OR'ed transitions are specified textually as a comma-separated list on the transition, as specified in §14.2.4.9:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Unfortunately the UML spec is not specific in that respect (I thought, but Jim has the right answer). Anyway:
14.2.4.9 Transition
The default textual notation for a Transition is defined by the following BNF expression:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Where is the standard notation for Triggers (see sub clause 13.3.4), is a Boolean expression for a guard, and the optional is an expression specifying the effect Behavior written in some vendor- specific or standard textual surface language (see sub clause 16.1). The trigger may be any of the standard trigger types. SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere.
There are other places in the specs where this paragraph appears in similar way, but without explaining how multiple triggers will be treated. I assume that it's an OR-condition. But that's only an assumption. Alas, since you have not seen examples (me neither) it is probably an unknown fact. Just don't use it - that's indeed possible ;-) And if you happen to find an example, just ask the author what he meant. UML is about talking to each other.
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 read a paper. It states that " For data sets, we used 10 realizations for parameter selection and 20 other realizations for parameter selection.
Does realization in this case mean simulation ?
Thanks
It would be better if you provided either (i) a link to the paper or (ii) more context, because at the moment it isn't clear what the sentence refers to.
My best guess is that it means 'realization' in the sense of 'a particular series that might be generated by a specified random process'.