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.
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.
i've this method findNegozio(insertID) used to find the element with insertID in a Collection.
So, findNegozio(insertID) is an operation that is often referred to in my sequence diagrams so I thought I would illustrate it as a sequence diagram.
The idea is to represent an iteration on a collection and take only the element that matches with the entered ID.
Could this be a good way to represent my idea?
is it useful to represent a frequent step of some sequence diagrams?
EDIT: Maybe with only one step is better OPT instead of ALT.
First three remarks :
For me your code is invalid because a return is missing after the loop => I suppose a variable result is added and initialized to null, set to the found item if exist, and finally used for a final return.
Are you sure findNegocio is not static ?
Why findNegocio is defined on Negocio and not on GestoreNegocio ?
A sequence diagram shows an interaction (partially or not) and focuses on message interchange between lifelines.
From the definition of your operation it is needed to decide whose messages are enough interesting to be shown in your sequence diagram. I don't think the details concerning the list and iterator have to be shown, they are very classical, the goal is not to explain how to work with Java builtin classes.
To break the loop you have the fragment break, so your sequence diagram can be (I added a caller because my tool does not manage lost/found messages) :
But perhaps the main information shown is the use of GestoreNegocio and the loop by itself is not really interesting ?
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:
I am designing UML Activity diagram in ArgoUML now.
I know that if I want to design condition like:
if(condition) {
doTrueAction();
} else {
doFalseAction();
}
It could be done in UML activity diagram like following:
But what if we have another condition inside the output of the previous decision? Like this:
if(condition) {
if(condition2) {
condition2TrueAction();
} else {
condition2FalseAction();
}
}else{
conditionFalseAction();
}
As you see conditionTrueOutput is being output and condition at the same time here. It seems to me that design is broken.
Edit: Or I should use fork element instead of decision (diamond) element?
I want to know how to design this correctly. Is there any rule?
There's a wrong assumption in your thoughts. A Decision has no output. It just has conditional control flows leaving it. Each can be guarded by a certain condition. This guard is written in square braces:
Note that I did not write the (implicit) [true] guard after the first test (rather by sloppiness when editing, but actually it can be omitted).
Edit My first though that your diagram has another flaw in that the actions have no control flow going out was incorrect. Actually Superstructures state that a missing outgoing control flow is equivalent to an FlowFinal after processing the Action. So your diagram is correct here.
Regarding your edit: as the comment says, this is for parallel continuation. Nested conditions need to be like shown above.
Edit2 As Ister noted in the comments, a Decision can have more than just the if and else control flow going out, but an arbitrary number greater than 1. The UML 2.5 states on p. 388:
If exactly one target of an unblocked outgoing edge accepts the token, then the token traverses the corresponding edge and all other offers are withdrawn. If multiple targets accept the token simultaneously, then the token traverses only one of the edges corresponding to the accepting targets, but which one is not determined by this specification.
In order to avoid non-deterministic behavior, the modeler should arrange that at most one guard evaluate to true for each incoming token. If it can be ensured that only one guard will evaluate to true, a conforming implementation is not required to evaluate the guards on all outgoing edges once one has been found to evaluate to true.
For use only with DecisionNodes, a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode.
It seems that your design is coherent but it is not a UML diagram. I suppose that you are mixing the activity diagram with the sequence diagram.
Your diagram looks like a sequence diagram but it tries to represent information that are related to the activity diagrams.
I suggest you this web site to investigate on the differences between the two diagrams, I hope it can help you.
Instead, by trying to use your design, what I suggest you is to insert another condition (e.g. SecondConditionAction) before the two condotion2.