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.
Related
I was wondering if you could help me clarify two aspects regarding multi-instance state machines.
First question
Consider an example state machine SM1 containing one state A:
On the left, transition start creates a new instance of the state machine. Transition stop terminates the instance.
There can be multiple instances of state machine SM1 running in parallel, e.g. 5 instances.
Now, what I want is a transition that would terminate ALL state machine SM1 instances that are running at the given time.
E.g. we create five state machines A and then transition stopALL would terminate ALL of them at once.
Is such behaviour permitted by UML specification? If yes, is there a graphical notation to unambiguously represent such a behaviour? I could not find the answer in the UML specification document.
Second question
Consider a multi-instance state machine SM2 with state A and one transition startStop:
The behaviour of the transition is as follows: upon firing, the transition creates a new instance of SM2 and terminates an existing one.
Is such behaviour permitted by the specification? Is there an unambiguous graphical way to express such a behaviour?
There is no special UML method but standard UML tools are absolutely sufficient. You need to broadcast a terminate signal (on state machine diagram you can represent it by behaviour on a transition that should terminate other instances). Then you just need to model that on terminate reception the state machine goes to final state.
Terminate All Example
Note that the behaviour after slash (/) is a behaviour invoked on a state transition i.e. when a state machine changes it's state into final the behaviour sendStopAllSignal is invoked which in turn should be described on a class diagram (with probably corresponding activity diagram)
Similarly you need to have a receiveStopAllSignal behaviour included in class diagram.
Terminate Existing At Start
This is similar situation - you need to have both sendStopSignal and receiveStopSignal modelled elsewhere.
Note however that such naming convention (sendAbcSignal for behaviour of sending/broadcasting signal Abc and receiveAbcSignal for behaviour as a reaction to Abc signal reception) is quite common, useful and self-explanatory (i.e. you probably won't model a separate action diagrams for those behaviours unless some extra logic is needed there).
How can I graphically represent within Statechart Diagrams that a state never gets executed more than a certain amount of times? So that it doesn't end in an infinite loop. Something like
assert enterPIN(int p) <= 3
and then branch to another state, if condition violated. Should I include it somehow in the guard? Or in the state activities?
EDIT:
(CheckPIN)--[invalid]-->(counter| + inc.)--[counter>3]-->(retainCard)
^ |
|-----[counter<=3]-----|
Something in this direction?
Legend: (StateName | (+-)activity), Transition: -->, [Guard]
I think your question is way too far down in the weeds. While you can model to infinitesimal detail, you should aim to create a much more durable model that will not require as much change over time.
H. S. Lahman makes an excellent case for using Moore state machines in his book, Model-Based Development: Applications. Moore state machines are where actions happen on entry to states, as opposed to where actions happen on transitions between states. His most compelling reason for using Moore state machines is that transitions do not degenerate into a sequence of function calls, they are instead announcements of things that have completed.
Here is an example of how to avoid all the detail and create a more durable model:
You'll notice that how things happen is completely encapsulated. For example, challenging the user might involve a PIN number, retina scan, or subdermal chip. The maximum failures allowed for each of those authentication modes might be completely different. That policy can be represented elsewhere.
To give a graphical answer:
This is how I would model it.
The counter object is usually not needed, since it's a simple counter and it's rather obvious that the rest/increment would refer to a common counter. Also there is no real <<flow>> to that counter. A not stereotyped dependency would also suffice.
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.
I build a UML state diagram and have a case where same transition to specific state exists from most of other states.
What is the most elegant solution to draw it?
Currently I though about two options:
1) Use junction pseudo-state with exit to my target state
2) Wrap source states in a composite and make a transition from it
Better ideas appreciated
Both solutions would be appropriate, depending on their legibility on the diagram. Too many transitions tend to clutter a diagram and make it difficult to read.
So if you have just a few source states (say less than 4), using transitions to a junction pseudostate (not a join pseudostate - different semantics!), it should be fine. The down side to this solution is that, if you want to get back to the original source state, you will have to store the information (e.g., as part of the signal).
If you have more, you can consider a composite state for all your source states. Note that if you do this, you can also have a transition to history to get back to the sub-state that was left, which may make your state diagram logic easier to implement (no need to store the state left) and the diagram easier to read.
I hope this helps.
Is it "legal" to for the only transition out of a composite state to originate from a decision node as shown in the picture?
http://pokit.org/get/?7358c1cf25ccd026b9ebe528768b0eb5.jpg
Yeah, I know the writing seems like I'm speaking in tongues. :) Apart from that, does the diagram make sense like this and is it valid according to UML rules?
Thank you for your time!
For full UML (2.5) compliance, you would need entryPoint and exitPoint pseudostates when you enter or exit a state. However, these are often not shown when there is no transition to/from a substate or when hierarchical state history is not tracked.
So you would need an entryPoint pseudostate on the Zapoceta state that would act as the "bridge" between the initial point and the Nepotpuna states.
Similarly, you would also need an exitPoint pseudostate in the Zapoceta state that would act as the "bridge" between the choice pseudostate and the Potpuna state.
Also, you would not need an "or" constraint on the transitions between the Obracunata and Placena states. What you would have are different triggers for each transition. Having multiple transitions out of a state machine implies that the transitions' triggers are mutually exclusive.