I have a question about statechart diagrams below;
I suppose that, in UML, it is possible. In this case, execution order is S1 enter, S3 enter. Am I right?
And In the next diagram, what is execution order when occured transiton from "any other state" to s1?
For the first diagram :
execution order is S1 enter, S3 enter. Am I right?
yes you are right, from the standard formal/2017-12-05 § 14.2.3.4.5
Entering a State page 310 :
Explicit entry: If the incoming Transition or its continuations terminate on a directly contained substate of the
composite State, then that substate becomes active and its entry Behavior is executed after the execution of the
entry Behavior of the containing composite State.
For the second diagram :
it seems to use an entryPoint pseudostate (badly drawn), but the transition from any other state is not going to it but to S1, so to the initial pseudostate, the execution is entryActS1 then entryActS2.
if it is not an entry point but a local transition from the border that changes nothing from any other state and the execution is also entryActS1 then entryActS2.
About the transition indicated internal
the transition from the possible entryPoint pseudostate or from the border is indicated internal, but internal transitions are self transitions where the source and target are the same state, as said in the standard formal/2017-12-05 §14.2.3.8.1
Transition kinds relative to source page 314 :
kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and
target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry
Behaviors are executed when this Transition is executed. This kind of Transition can only be defined if the
source Vertex is a State.
So the second diagram is illegal :
in case of an entry pseudostate rather than to be internal the transition from it is local as said in the standard formal/2017-12-05 § 14.5.11.8 Constraints page 361 :
state_is_local
A Transition with kind local must have a composite State or an entry point as its source.
in case of a transition from the border it can be local or external, but as it is drawn it is local, see standard formal/2017-12-05 page 335 figure 14.34 Local Transitions and Figure 14.35 External Transitions to see the difference of drawing
Related
I have a state machine diagram for an application that has a UI and a thread that runs parallel. I model this using a state with 2 parallel regions. Now I want when that thread gives some message, for example an error, that the state of the UI changes, for example to an error screen state.
I was wondering what the correct method to do this is, as I was not able to find any example of this situation online.
The options that I thought of were creating a transition from every state to this error state when the error state is called, which in a big diagram would mean a lot of transitions. Or by just creating a transition from the thread to the error state (As shown in the image), which could possible be unclear.
Example of second option
You don't need a transition from every state. Just use a transition from the State State to the Error window state. It will then fire no matter what states are currently active.
Such a transition will also leave the Some process state. Since you didn't define initial states in the orthogonal regions, the right region of the state machine will then be in an undefined state. Some people allow this to happen, but for me it is not good practice. So, I suggest to add initial states to both regions. Then it is clear, which sub state will become active, when the State state is entered for any reason. The fork would also not be necessary then.
How you have done it in your example would also be Ok. However, since the Some process state is left by this transition, this region is now in an undefined state. Again, the solution to this is to have an initial state here. I would only use such a transition between regions, when it contains more than one state and the On error event shall not trigger a transition in all of the states.
If the Some process state is only there to allow for concurrent execution, there is an easier way to achieve this: The State state can have a do behavior, that is running while the sub states are active. Orthogonal regions should be used wisely, since they add a lot complexity.
According to the state machine below shown in chapter 9.3.3.6 Transition 011-C of the document Precise Semantics of UML State Machines from OMG it's fine to define a local transition from a substate to a containing state.
But what does that local transition T1.3 do when it's executed? I supposed that state S1.2 is left and after that the default entry of state S1 is applied, hence transition T1.1 is executed and finally state S1.1 is entered.
However, the run-to-completion steps table of that chapter shows that after transition 1.3 is executed, the completion event CE is generated and thus the state S1 is left by transition T3:
This left me puzzling, as the UML specification 2.5.1 states in chapter 14.2.3.8.3 Completion Transitions and completion events that a completion event of a composite state like S1 is only generated if all it's orthogonal regions have reached a final state. This certainly is not the case in the state machine shown above.
Now, which behavior is correct? May it be that the run-to-completion steps table is wrong?
The shown sub-state machine uses a so-called local transition (see the link in #Roman's comment). UML 2.5.1 describes a local transition on p. 314
kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State.
Examples of local transitions can be found on pp. 334 of the UML 2.5.1 specs.
So the sub-state machine will never exit and thus table and diagram do not match. Likely the author made a mistake and meant what I stated in my original answer below.
Original answer:
I never have seen the notation above, but assume that it should picture a sub-state exit (so T3 will be the next transition which complies with the table).
I guess the notation should rather be using a Final like this
shown in fig. 14.38 on p. 339 of the UML 2.5.1 specs.
I supposed that state S1.2 is left and after that the default entry of
state S1 is applied, hence transition T1.1 is executed and finally
state S1.1 is entered.
"T1.3" should lead to "S1.2" being left, "S1" remains active. "S1" is not left and not re-entred because "T1.3" is a local transition.
The only region of "S1" is not finished as no Final State was entered. Thus no completion transition.
May it be that the run-to-completion steps table is wrong?
Yes, I believe it is wrong.
This topic still did bother me despite your appreciated answers, thus I did some further study. On page 31 of the document Precise Semantics of UML State Machines I found this:
Completion of a region activation
RegionActivations never reach completion by being exited either
implicitly or explicitly. There are two ways to complete the execution
of a region.
The general rule is that a RegionActivation can only complete if a
FinalStateActivation (see 8.5.5) for a FinalState owned by the
Region is executed. This leads the RegionActivation to be marked as
being completed (its isCompleted attribute is set to true).
The above general rule is violated only in the situation where a
VertexActivation owned by a RegionActivation is exited and the
TransitionActivation that exits that VertexActivation has as its
target the StateActivation owning the RegionActivation. In this
case, and only in this case, does the RegionActivation that owns the
exited VertexActivation complete.
If I'm understanding this correctly, then rule 2 describes exactly the behavior of the state machine 9.3.3.6 Transition 011-C and in that case the run-to-completion table is actually correct.
How can the following be expressed in UML:
I have a class, whose behavior is modeled as a state machine. On entry
to a particular state in that state machine, I want to invoke an
operation (method) of the class instance.
I'm trying to figure out the formal way to capture the relationship described above. I know that entry behaviors of a state can be of different types (e.g., FunctionBehavior). Classes can have Operations which are essentially specifications for a function (like a function typedef). I'm confused as to how to specify a function as implementing a particular Operation, and then have it be invoked from potentially multiple state entry behaviors.
Citing Superstructure for 2.5 (chap. 14.2.3.4.3 p. 307):
State entry, exit, and doActivity Behaviors
A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.
A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
it completes (in which case a completion event is generated) or
the State is exited, in which case execution of the doActivity Behavior is aborted.
The execution of a doActivity Behavior of a State is not affected by the firing of an internal Transition of that State.
That means you can define an operation in the class which is executed when the state is entered. You show it this way:
Edit: Just copying Geert's comment below to make it water proof :-)
The UML specs are quite specific saying that the state has an associated Behavior. The Behavior might be the method of an operation but it doesn't have to be. Since Behavior itself is an abstract meta-class it can be any of Activity, OpaqueBehavior, FunctionBehavior, Interaction, StateMachine or ProtocolStateMachine
As a newbie am trying to develop a state machine using Visio for a cd writer. below are the device operations/transactions and attached, is a diagram of what I've done so far, am unsure if its accurately represented.
Device operation
Load button- causes the drawer to open and to shut if open(load an empty cdr)
Burn button- starts recording document on the cdr, green light comes on in the burning process
and goes off when completed. Once cdr is burned writer stops.
Verify button- verifies the document previously recorded on the cdr, green light comes on in the
process and goes off when completed, then device stops
Cancel button- stops process anytime during recording or verifying
Cancel button- no effect if cd writer is empty or not busy verifying or recording When powered up- CD Writer will ensure the drawer is closed
Burn button – has no effect when cd writer is empty and during recording or verifying process.
Verifying can only be started when the CD Writer is not busy recording.
Visually your diagram looks like a state machine and states have good-sounding names - it's a good start. :)
The first issue I see there is the transition specification. It is definitelly not correct. State transitions in UML are specify in the folowing format:
event [guard] /action
where:
event (or trigger) is an external on internal "signal" that starts the transition. It can be a button activated by a user, an elapsed timer, a detected error, etc. It can even be omitted.
guard is a logical condition that should be fulfilled in order to start the transition. It is usually an expression returning a boolean value of tru or false. It can also be omitted.
action is a kind of side-effect, something that is executed when the transition is triggered. Ic can also be omitted.
Getting back to your diagram I would say that...
most of the labels on your transitions should not carrry "/" as it indicates an action. There are mostly manual triggers, like "load" (pressing the button to open the drawer), "Cancel", "butn", etc.
Consider some events that are triggered internally, like "burning done", or "CD loaded"
You can add some guard conditions in the situations where possible
I would remove all the triggers with no effect (like cancel with no CD in). It makes the diagram simplier with no loss of information
States LOADED and IDLE in your case are kind of strange, weak. It is not clear what makes them different (see the example below)
Here is a diagram that I find a bit more acurate (see notes for additional comments):
You need to specify explicit events as triggers of the transitions.
In the current state machine, each transition (except the one leaving the initial vertex) has an effect, but not a trigger. More accurately, they are triggered by the default completion event, and are therefore automatic.
Moreover, since all transitions react to the same event, your state machine is non-deterministic. For instance, in the state loaded, the transitions to Recording, empty, and loaded all react to the completion event. When the completion event is dispatched, these transitions are said to be conflicting, and one of them is selected non-deterministically. I am sure this is no what you want.
Read the UML Specification, and define triggers for your transitions.
You don't need to depict the transitions from "empty" to "empty" as transitions without any actions or state transitions would not need to be drawn in the Statemachine diagrams. (State Transition tables are often used for the checks of any missing transitions for such cases.)
"loaded" and "Idle" can be represented in one as a same state
To represent the "green light", I would write "turn on the green light" as entry action in Recording and "turn off the green light" as exit
Here's the diagram I drew. The status of tray (whether its opened or closed) should be considered in the actual model, but its not on my sample diagram below.
Base on Wikipedia, I can have a hierarchical state decomposition, where I have multiple orthogonal regions, which can change state independently.
The diagram shows how the orthogonal regions are entered. I assume that the entry happens in parallel in all regions. What I want to know is, how do you express the exit? If each region has an exit, does the global parent state exits when the first child region exit, or when they have all exited? I want to express that the exit happens when they have all exited. And how do you express that the global parent state transitions to the next global state because all children regions have exited? Is that always implicit?
My concrete problem is that my FSM starts in the Initializing global state. It sends multiple queries to multiple external systems asynchronously in parallel. Only once it has received the answer to each query, it can then proceed. So I model each asynchronous parallel query as an orthogonal region inside the global Initializing state. Each child region can change state independently. When all child regions have reached an end-state, I can move on.
The FSM will be implemented in an Actor framework, where asynchronous messages (events) are the only way to communicate.
Ideally, I'd like the answer to point to an example image, as such things are difficult to express in words.
A completion transition from the orthogonal state will do the trick, since it will be taken when all of the orthogonal regions have finished.
When an composite state (state with inner states and/or orthogonal regions) is entered, each region starts at its initial state, to a different state in each region using fork pseudonodes, or to the last state of each region if the state is entered through a history pseudostate. Exiting the composite state can be done through a transition that starts at one of the inner states, which exists all of the orthogonal regions from their current state. If you want to exit when a the machine has come to a set of states in different regions, you can also use join pseudostates.
As you can see, the possibilities are almost endless. I can't add an image yet, but I'll do it later when I have a good UML editor at hand.
An now the example. Suppose you have the following state machine:
If both parallel regions finish (arrive at a final node), then the completion transition will take the machine from S1 to S5. If the
If the machine is currently at S3 and receives e1, it will exit S1 and go to S6.
If the machine is in S7 and S8 and they both finish, it will go to the join and then to S6.
This is the way I know state machines work.