UML: final state - uml

Let's assume we have the following state diagram (from UML reference book) which describes states of some object:
If object now is in state Y and e event is triggered will the object come in state Z after coming to final state, assuming that after e event there are NO more events? I am asking as for me it is not quite clear.

Citing Superstructures for 2.5 (FinalState):
14.5.2.1 Description
A special kind of State, which, when entered, signifies that the enclosing Region has completed. If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed.
That means in your concrete case: when e happens the state X is finalized and transfers unconditionally to z.

Related

In UML, how do you call the object for which you build a state diagram?

State diagrams in UML are always constructed for a specific class (that is, to describe the behavior of instances of that class). Thus, every state diagram is associated to a specific object for which it defines its behavior. What is the name of this object? the closest I could find in the UML standard is the term 'context object', as in here (section 14.2.3.1 in UML v2.5.1):
The event pool for a StateMachine execution belongs to either its context Classifier object or ...
But I could not find anyone that uses this term.
I use an answer to not have to cut the following in several comments.
State diagrams in UML are always constructed for a specific class
You have to speak about state machine, not about diagram, and in your case visibly you speak about behavior state machine (not about protocol state machine).
A diagram is just a picture showing a part of the model.
Thus, every state diagram is associated to a specific object for which it defines its behavior. What is the name of the object?
That depends, if your state machine defines the behavior of an operation then your object is that operation and its name is the name of the operation.
that is, to describe the behavior of instances of that class
If I well understand this is from where your error comes from. You are focused on instances of class, but a state machine does not define the behavior of instances of a class, so to try to know the 'name' of theses instance as no sense.
Perhaps someone who has worked on the still-unadopted Precise Semantics for State Machines specification at the OMG will correct me if I’m wrong, but I believe there are three possible execution contexts.
The first is that of an “active class”, where each instance runs in its own thread and you send signals to it. The second is that of a normal class, where you call operations on or send signals to a normal instance, in the usual way. The third is that of a BehavioredClassifier, where each instance starts a special classifierBehavior as soon as it is created.
§13.2.3.5 of the UML 2.5 spec says:
The receiving object becomes the context object for the execution of
any invoked methods.
NOTE. Methods of a Reception are always invoked asynchronously, while
the methods of an Operation may be invoked either synchronously or
asynchronously, depending on how the Operation is called.
A state machine is defined for one of those execution contexts to determine how an instance will respond to a particular event, given its current state.
Yes, every state machine (possibly depicted in a diagram) is associated with an object, but it is not some specific object with some special name. Rather, a state machine governs how every instance of a particular class will respond to events, given its current state. And the name of an instance is whatever variable happens to hold a reference to it.

UML Statemachine - Reuse state

I'm trying to model a state machine which reuses a state in order to reduce complexity.
I've got three states: State A, B and X.
My state X can either be entered via a transaction from state A or B.
State X includes multiple substates with lots of complexity and I don't wont to implement it twice.
After the process in state X is completed I need to transition back to back to state A or B based on which one was the previous state.
Is there a elegant way to solve this?
State X includes multiple substates with lots of complexity and I don't wont to implement it twice
Define a submachine corresponding to your state X and in your current machine use submachine state to instantiate it where you need
See §14.2.3.4.7 Submachine States and submachines page 311 in formal-17-12-05 :
Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices.
...
NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine.
A SubMachine will help you to reuse several time part of your state modelling.
But if you want to be able to enter into your state X from A or B and then retun to the previous state, ShallowHistory Would be a good idea.
In the following state machine, I modeled a SubMachine X referenced by both states X1 and X2. I also wanted to model the fact that state X2 in processed after A or B and then next state if the previous one.
Another solution consists in playing with transition guards or events/triggers. You must keep in mind that transitions are triggered when specific events occurs or when its guard is true cf. following screenshot.

Is a state without a direct transition allowed in UML state diagram?

Is a state without a direct transition allowed in UML state diagram (SD) like the below drawn with StarUML?
State1 is not directly involved in any transition so I'm in doubt wether this is allowed in UML / desirable. I think in my application I'm actually modeling multiple objects in a single SD.
In short
Based on the UML 2.5 specifications, this kind of diagram is perfectly valid. Nevertheless, by deduction, we can understand that it is not the best approach.
The details : why it is valid
According to the definitions (section 14.2.3.4.1):
State1 is a composite state made of exactly one region.
State2 and State3 are simple states, and in this case they are also direct substates of State1
A first answer to your question is suggested by the rules on entering a state (section 14.2.3.4.5):
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 ...
This is also reinforced in the rules related to regions (section 14.2.3.2), and more precisely to their activation:
Either a region starts with its own local initial pseudo-event (that is automatically activated when the enclosing state is activated, or one its "orthogonal" regions (i.e. concurrent in the same composite state) is activated.
Or a region starts at an explicit state (substate) if the region is activated by an entering transition:
an explicit activation occurs when a Region is entered by a Transition
terminating on one of the Region’s contained Vertices.
So your diagram is perfectly valid, with an explicit transition from initial state to the substate State2.
The details: why it is not recommended
First of all, it is suggested (section 14.2.4.5.1) that it may help in some case to hide the decomposition of a composite state:
With explicit activation, such hiding would require to draw a variation of the model, showing a transition from initial to State1 instead of the direct transition to State2.
With default activation, you'd have only one model: initial to State1 and State1::initial to State2. Up to you to show or hide the details. Or to zoom into the region ignoring its context.
Then, if you'd later need to extend your composite state with multiple "orthogonal" regions:
with default activation, you'd just add additional regions with their own default activation.
with explicit activation, you'd have an asymmetry between one (explicitly activated) region, and the other regions (that require default activation).
alternatively, you could consider having multiple explicit activations. But this is not well supported: first there is no transition with multiple targets, second, multiple transitions from the (external) source state to the different (internal) target substates, would be ambiguous in regard of the semantics and execution model of transitions.
The UML specs warn that if default activations are missing, one should consider the model as ill-defined, or that the region will never start. So it's safer to use a systematic approach, and always use default activation.
State1 subsumes State2, so an indirect transition does exist for State1. That diagram is equivalent to having a transition to State1 with a default transition to State2, which would be overly messy.
The diagram is a valid UML state machine diagram of a single object (not two objects, as you suspected). However, State1 is not useful, because the object will always be in State1 during its entire lifetime. While in State1, it will either be in State2 or in State3 as well.

In a UML state machine, can an initial pseudostate have incoming transitions?

In UML 2.5.1, the initial pseudostate of a state machine is defined as follows:
An initial Pseudostate represents a starting point for a Region; that
is, it is the point from which execution of its contained behavior
commences when the Region is entered via default activation. It is the
source for at most one Transition, which may have an associated effect
Behavior, but not an associated trigger or guard. There can be at
most one initial Vertex in a Region.
In other words, a UML state machine should almost always contain exactly one initial pseudostate, which should have exactly one outgoing transition.
However, can an initial pseudostate have incoming transitions as well? For example:
I cannot find anything forbidding it in the UML specification, yet I cannot find any example online where this case happen, therefore I was wondering whether or not I overlooked anything.
EDIT: To go into more detail, if we look into the OCL constraints stated in the specification, we can only find the following one that affects outgoing transitions (section 14.5.6.7):
inv: (kind = PseudostateKind::initial) implies (outgoing->size() <= 1)
but I cannot find any constraint regarding incoming transitions
EDIT2: I have just realized that my model is wrong! Considering this sentence of the specification (cited above): "It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard."
Therefore the transition between init and s1 should actually have zero triggers, instead of having e1 as a trigger.
Note that while this does not invalidate the initial question.
I see nothing in the UML 2.5.1 Specification that prohibits a transition whose target is the initial pseudostate.
Such a transition would be meaningless at best and confusing at worst, which is likely why no examples are found.
Edit: see the comments!
On p. 423 UML 2.5:
15.7.18 InitialNode [Class]
15.7.18.4 Constraints
• no_incoming_edges
An InitialNode has no incoming ActivityEdges.
inv: incoming->isEmpty()
N.B. If you intend to have a self-transition for e1 then why not just using that? The Initial can anyway have only on singular outgoing edge, namely to the first state (here s1).
No this is not allowed. And why would one Do that? As you already stated in the cited text,it can only have one outgoing edge without any guard. So what is the added value, as you cannot reuse anything.
I think the text is pretty clear as-is: "[An initial Pseudostate] is the point from which execution of its contained behavior commences when the Region is entered via default activation." If you connect a transition back around to the initial psuedostate, the initial psuedostate is no longer "the point from which execution of its contained behavior commences," it is something else, and is therefore undefined.

UML State Machine: Transition selection

I'm trying to collect informations to be able to program a correct transition selection algorithm for an UML State Machine.
The UML Superstructure Specification (15.3.12 StateMachine) states
Only transitions that occur in mutually orthogonal regions may be fired simultaneously.
Does "mutually orthogonal" imply that the regions are on the same nesting level?
For each state at a given level, all originating transitions are evaluated to determine if they are enabled.
This sounds to me like they have to be on the same nesting level. Right? Because if a transition is found on a certain nesting level, the search ends...
The seciton "Transition selection algorithm" once again is not totally clear to me:
The only non-trivial issue is resolving transition conflicts across orthogonal states on all levels. This is resolved by terminating the search in each orthogonal
state once a transition inside any one of its components is fired.
To make this a little more haptic I created 2 models:
Model 1
Model 2
Active state configuration:
State1, State3, State4, State7
Example 1a
In case of an event Event1 which transitions fire?
a. Does only the one from State7 to State 5 fire?
b. Or also then one from State3 to State8?
Both variations would yield in a legal active state configuration.
But my understanding is, that a is correct
Example 1b
Same for model 2.
Example 2a
In case of an event Event2 which transitions fire?
a. Does only the one from State7 to State 5 fire?
b. Or also then one from State3 to State2?
In this case I would say that b would lead to an illegal active state configuration.
Does this mean the model is ill-formed or would only one of the transitions be fired?
Example 2b
Same for model 2. Any difference?
I'd interpret mutually orthogonal to mean that the side effects of the transitions have no impact on each other.
So in either of your diagrams, the transitions triggered by Event1 can be deemed to be mutually orthogonal as the transitions are both contained within [A] and [B] and may be fired simultaneously. Event2 cannot as the transition from within [A] leaves A and State1 (and therefore also [B]).

Resources