I want to represent a break in an iterative expansion version in UML 2.4.1.
I tries this:
With exit arrow to the region:
With no exit arrow:
With an end flow:
What is the correct convention ?
There is no convention for it. It depends simply on what you want to say.
The first diagram is incorrect as Add does not lead to any end. You need to connect it to wherever reasonable but not leave it stuck "in the air".
The second even more for twice the reason.
The third is the same as the first. You can use the Flow Final instead of transferring control to the expansion node. You would do that if you have complex flows with many of such interim exits. For the simple case here you will not need it.
Please note that there is also a possibility to use a Initial inside the region. You would use that if you have multiple inputs and want them to start at the same point inside.
P.S.: I overlooked your question while starring at the bugs in the diagram. The break condition can be shown by a guard in the transition which leads to a Flow Final or connects to the output pin.
Alternatively, to interrupt processing all collection elements you get passed you can do this:
This treats the preemptive loop as an exception.
I would also say that a simple note would suffice unless you want to generate code from your model.
A bit down in Superstructures I found this:
When the ExpansionRegion completes all expansion executions, it offers the output collections on its output ExpansionNodes on any ActivityEdges outgoing from those nodes (they are not offered during the execution of the ExpansionRegion). If the ExpansionRegion contains an ActivityFinalNode immediately within it, then, if the ActivityFinalNode accepts a token within any expansion execution, all currently ongoing expansion executions are terminated and the ExpansionRegion as a whole completes its execution. In this case, output collections are still offered from the output ExpansionNodes, though the collections may only be partially filled.
Which confirms my first statement from the P.S.
Looking at the OMG UML spec:
First & Second Diagram:
Please refer to section 14.3.5 Examples which shows as I understand it that a state with no exit state is a terminal state for the submachine/composite state that contains it.
Third Diagram:
You are saying aborted/terminate vs final state. Different things happen can happen. See page 338. I think you mean final state as expected, not in error, so avoid the circle with an X. Does not allow for normal execution to complete.
"terminate – Entering a terminate Pseudostate implies that the
execution of the StateMachine is terminated immediately. The
StateMachine does not exit any States nor does it perform any exit
Behaviors. Any executing doActivity Behaviors are automatically
aborted. Entering a terminate Pseudostate is equivalent to invoking a
DestroyObjectAction."
Summary: It is subjective, but lines matter as behavior can be attached and they can be named. If we take the ATM examples (336-340)pg in the spec, they have been there for many UML versions, then I would say leaving it, if needed connecting it to an edge/exit point, or final state circle with a filled inner circle within the composite state <<iterative>>. Now I am not sure what tool you are using, but that might be worth consideration. Not sure what the broader context is.
Related
I'm new to SysML and modeling in general and this is for the purpose of learning.
I have an activity diagram and multiple calls to a "Call behavior" and would like the calling activity diagram to continue from where it left off, after the Call behavior has finished executing.
I tried using guards, even though that is not exactly accurate, but that did not work for me either.
The left part of the diagram shows a merge node with a control flow to "Verify_And_Map_Data", and the intention is for all three operations to repeat the call behavior in sequence.
The sequence intended is :
Initialize_Master_Follow_Data
Verify_And_Map_Data
Initialize_XOR_Data
Verify_And_Map_Data
Initialize_Feedback_Linked_Data
Validate_Motor_Start_Stop
Edit: Thanks qwerty_so . How about this one, it pretty much contains the same elements and control flow, exempt for evStartAnimation,, and organized in a top down way.
Top-Down_Activity Diagram
I'm working on a project and trying to show one of the Use Cases in a UML activity diagram.
I'd like to use it in order to show that the requirements for this particular use case are met.
I'd also like to use it to develop the test cases that will need to be written for this use case.
I've ordered the "UML 2.0 In A Nutshell" book but until that arrives I'm trying my best from articles and youtube clips so the diagram may not conform to the proper standards.
Question 1:
I've tried to show that the ExecuteInThread function as a whole has a try catch block to stop any exception bubbling up and crashing the app but I'm not sure if I've shown that correctly?
Question 2:
I'd also like to show is that updating the task status to Failed / In Progress / Completed is done on the database and if the database is unavailable it retries 10 times to connect before it fails.
Is it possible to have a repeatable block on the side I could refer to for each Update activity to show this?
Question 3:
I've read that at the level of the use case I should not be showing any implementation details.
I'm guessing this means avoid showing there's a database involved at all and not to show any try / catch logic unless it impacts the user's actions. Am I doing completely the wrong thing here?
The retry logic is a requirement for this use case though so my first attempt was to include it given it would help with writing the test cases and showing application resilience.
Diagram:
Question 1:
Any action can be protected by an exception handler. This is the zigzag-line in your diagram. The action at the other end is the handler body. I must not have incoming or outgoing control or object flows. When the exception handler finishes, the protected action produces tokens on its outgoing flows, as if it has ended normally. The handler body should also have an input pin typed by the exception. This way it can distinguish different exceptions and the protected action can tranfer information about the problem.
Structured activity nodes are also actions and can be protected by an exception handler. In your diagram I guess Execute Task in Thread is such an action. The official notation uses a dashed border and the keyword «structured».
Edit: After discussion with #bruno.
If you want to use Exceptions, you should probably rethink how you group the actions. A protected action will always finish successfully, if its exception handler body doesn't raise a new exception. That means the body must try to recover from the exception and potentially retry the behavior of the protected action (there is no UML element for retrying, you will have to do it on foot). If that doesn't work, the handler body must reraise the exception (after having made sure that everything is in good order, i.e. that the class invariant is still holding).
This might seem a bit over complicated. Why not simply use a decision node after the action execute task with the guard [successfull]. I would use ReceiveSignalActions in use case flows only to model interactions from outside of the system, that can influence the flow of the use case.
Question 2:
You can create an activity update task status and call it from all the update actions. The status itself could be a value pin on this call action. Inside the update activity you can show a loop with decision and merge nodes that counts the trials. However, it will probably be easier to just write in the description, that it can be Irepeated 10 times.
This is the way how a repeatable set of actions can be modeled. It is not possible to do that in the same diagram. I would however be allowed to expand one of the call actions, so that the called activity is shown there. You have to try, whether your tool does offer this possiblity. Some tools only offer to show any diagram embedded in another diagram. This is not standard and will not be interchangable between tools.
Question 3:
I agree that the database and the number of retries are technical details that are not the focus of the use case analysis.
It could be interesting, though, if the system would not just display an error message, but would need to offer alternative ways to achieve the desired result. If for example the system shall then offer to save the update to an usb stick. Since this requires additional interaction with the user and gives rise to a new functional requirement for the system, it makes sense to analyse it within the use case. If it is just an occasional technical problem, I would not cover it.
If you need a way to capture this requirement in your model, I would just add a user defined extension for textual requirements. Not all requirements are coming from use cases. Many tools already have their own extension for this.
In a sequence diagram, when should a message originate from an occurrence specification and when should it originate from an execution specification?
Likewise, when should the message's target be each of the two?
Clarification of terms
I understand that the terms occurrence specification and execution specification might not be familiar to most, as such I point them out on a sequence diagram.
In the following depiction, there are two messages (marked in red):
m12 which leads from and to occurrence specifications, and
m2 which leads from an occurrence specification to an execution specification (the cyan-coloured block).
(source)
Most tools capable of drawing UML sequence diagrams place an execution specification on both sides by default -- why is that? -- as is the case with Visual Paradigm
and MagicDraw
A nice summary of the terms is found at uml-diagrams.org.
The UML spec says on pp. 578
An ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification.
and
An ExecutionOccurrenceSpecification is represented by the start or finish endpoint of the vertical box for an ExecutionSpecification on a lifeline. See Figure 17.2.
So they just mark the point in time when something happens. Actually there are a number of examples in the spec where timing constraints are also applied in conjunction with ExecutionOccurrenceSpecification.
On p. 567:
ExecutionSpecifications are represented as thin rectangles (gray or white) on the lifeline (see 17.3.4 (Lifeline)).
We may also represent an ExecutionSpecification by a wider labeled rectangle, where the label usually identifies the action that was executed. An example of this can be seen in Figure 17.16.
Simply speaking: there is something happening in a black box.
Now for an OccurrenceSpecification there is a recursive definition in the specs on p. 566:
The semantics of an OccurrenceSpecification is just the trace of that single OccurrenceSpecification.
The understanding and deeper meaning of the OccurrenceSpecification is dependent upon the associated Message and the information that it conveys.
(Wow!) But then on p. 567:
OccurrenceSpecifications are merely syntactic points at the ends of Messages or at the beginning/end of an ExecutionSpecification.
Actually an OccurrenceSpecification is just a more general form of the ExecutionOccurrenceSpecification.
While fig. 17.2 uses ExecutionSpecification the following figures 17.3 etc. do no use them. So you are free to use them at your will.
The point where the message starts/ends is always an occurrence.
The execution specification shows the instance that is active. For the initiating instance it is not defined if there should be an execution occurrence or not. Thus various case tool developers took various approaches. If you can decide, you can depict if the instance remain active (e.g waiting for an answer) but that's modeler's choice.
Your question was, why some tools show execution specifications on both sides. The reason is simply, that their support for Interaction Diagrams is sorely lacking. Neither the sender nor the receiver of a message is required to execute anything, thus no execution specification is necessary.
While it might often be the case, that the sender executes some behavior, in the course of which some message gets sent, and that the receiver of a message executes a behavior in reaction to receiving a message, this is not always the case. The sender might send spontaneously and the receiver might ignore the message. Even if something gets executed, the modeler might choose not to mention it. An Interaction diagram shows some interesting occurences, but it is by no means required to show all possible occurrences.
A message might start or end at an ExecutionOccurrenceSpecification, but it could also just be a MessageOccurrenceSpecification. An ExecutionSpecification could also be independent of a Message. Maybe the modeler wants to express, that an Object is executing something, whithout beeing disturbed by any messages. It is even possible to define the behavior that is being executed. However I have not found a tool that supports this mandatory feature of UML.
So the answer is, that the tools should allow any combination of Messages and ExecutionSpecifications, since it is entirely up to the modeler, which Occurrences she wants to show.
What happens in an UML state machine if the transition selection algorithm (TSA) finds two transitions that should both fire and the following holds true:
transition #1 ends directly in a state
transition #2 ends (intermediately) in a choice pseudostate
As both the transitions fire, they cannot be in conflict. Else they would not have been chosen by the TSA in the first place.
Now the following occurs:
As the choice is evaluated (after transition #2), it takes a path (transition) that would lead to the exit of an ancestor state of the source state of transition #2. Due to this exit of an ancestor state, a conflict with transition #1 occurs.
UML diagram showing such a situation
(improved according to the discussion with Thomas Kilian in comments to his (now deleted) answer)
... if Event_1 occurs and x < 0.
Questions
Is the state machine ill-formed or what is supposed to happen now?
Is it illegal for a transtions after a choice to exit a state? At least it doesn't play together well with the "transition execution sequence" (exit(s), transition behavior(s), enter(s)). As it would be exit, behavior, exit, behavior, enter(s) in that case. I could not find anything about that in the UML Superstructure Specification (chapter 15). But then everything about orthogonal regions is very vaguely described in that document...
Motivation
I am asking the question out of the perspective of a library implementer. So my focus is not on how to design this situation in a nicer manner. I need to figure out how to deal with this situation correctly (or I need to know that it is an illegal situation).
This is one reason why there is a "Precise Semantics of UML State Machine" at the OMG...
First, it is legal for most transitions to exit a state. There are a few restrictions in the UML spec, but none that would concern your design.
You should always have a single state that is potentially active within any state machine region. As it stand, you have an implicit region in your "StateMachine1" that contains both the "X" and"Y" states. This would mean that your state machine could be in both "StateMachine1::X" and "StateMachine1::Y" states at the same time! As you probalby already know, orthogonal states are there do deal with such a situation. Perhaps you need to bring "X" and "Y" within state StateMachine1::S' regions?
Also a warning that by default in UML, states have shallow history. This means that, as it stands, the initial transitons within StateMachine1::S' regions will only be taken once. If you try to get back into "S" (I know, you don't have a transition for that - just speculating), it will go back to the last states (one per region) before if left the state, which, after event1, would be "A" and "E".
It would be difficult to comment more without knowing what you are trying to model, but I hope this helps.
I have made an activity diagram for gym management, but i am facing a problem how will i connect Receptionist with Admin, According to requirement activity between Admin and receptionist takes place only through notification and i have made a signal and receptor for notification. Please also check if every notation is right and suggest me for modification?
I am sorry for not answering at once - several times had I looked at your picture, and, frightened, retreated.
You really tried and did something. It is good. But... You have put Use Cases directly into the activity diagram. So as is, it has no sense.
Let's take a customer. He has his swimlane. Good. According to your diagram, the customer comes and decides, what to do - immediately leave, join or inquiry. It doesn't matter, if he joins or inquiries, the result is common (why had he been choosing?) - he gives some unknown message to the receptionist. He never gets something back, never he does smth. else, he remains here and becomes immortal, because even his death won't finish his state of being here, waiting for some reaction from anybody. Poor man!
I don't think it is necessary to analyze here other swimlanes - they are even worse.
Better divide your work into levels.
Use Case diag. Define, who are actors (you have defined them well) and what are their interaction with system and its parts.
As the next stage you can make a deployment diagram - where are components of the system and maybe, actors, located and what messages they send to each other, defined.
And only now you can start with Activity diagram.
Also notice, that you'll have to return and correct the elders diagrams when you'll come to a dead end or some radical changes in the younger ones. You'll meet with both, be sure.
And when you have some problem with some diagram, come here, write down what you had BEFORE it (you didn't), what you have done on this stage (you did it) and we'll be able to help.