What is the interpretation of the following quoted sentences from UML Reference Manual?
When an orthogonal state is entered, the number of control threads
increases as a direct substate in each orthogonal region becomes
active.
When the orthogonal state is exited, the number of control
threads decreases.
This is a complex part of the UML spec. In the simplest case, when you enter a state containing orthogonal regions, the initial psuedo state in each orthogonal region essentially starts a separate thread of control. There are lots of complicated rules about how events are consumed by these threads and how the threads join back together.
But, according to a methodologist I highly recommend (H. S. Lahman), you really shouldn't use more than plain old Moore state machines. For more information on why one should use Moore state machines (which you can model perfectly well in UML) instead of Mealy or Harel state machines, please see this excerpt from Lahman's book. For more information on the difference between a Moore and a Mealy state machine, please see
this StackExchange question.
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 am working on an RTS game and I want to be able to build structures, which means that a builder will walk to target location and, once there, start building.
I want to implement a statemachine in every unit where states can be added as the user gives input because this might come in handy later, when units guard position and stuff.
My question is: is it useful to create a statemachine for every individual, user-owned unit or is this a pitfall?
State machines are common in games.
A state machine is the usual approach for behavior of objects, NPCs, etc in games.
They are so commonly used that they are often supported by game engines: e.g.: Unity
A state machine pitfall might be resource consumption by a naive implementation, e.g. one employing a State Pattern, which is ok only if don't have relatively few state machines running at the same time, otherwise resource consumption of a State Pattern would be prohibitively high for thousand of concurrent state machines.
If you indeed intend to have thousands of individual state machines running at the same time, or need extreme efficiency, you will have to implement them with a simpler approaches: eg: nested switch statements or table based implementations examples in C.
Reasons for using State Machines, in general, not only in games.
The main reason for using state machines is modeling your problem with clarity: You can think about edge conditions visually, by drawing out the state machine, e.g. by using tools such as GraphViz or by hand.
It easier to see what would happen in which scenario, precisely.
Sometimes your problem "just calls" for a State Machine representation: it has "states", and complex behaviors, which depend on past events.
State machines have decades of computer science research behind them, and algorithms about analyzing them, simplifying them, etc are known.
If you try to model a state machine "by adding and removing IF statements", by hand, you will end up with messier code, which you won't be able to transform, model, etc.
On the "cons" side, if you use table based state machines, debugging them would be somewhat hard.
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 heard people using these terms.
I wonder if they refer to the same thing or is there a difference between these two?
Wikipedia actually covers this pretty well. http://en.wikipedia.org/wiki/State_diagram
State machines have been around for a long time (decades at least). They consist of states (usually circles) and arrows between the states where certain actions can trigger an transition along an arrow. Moore and Mealy machines are the two main variants, which indicate whether the output is derived from the transitions or the states themselves.
Statecharts were invented by David Harel, and are sometimes called Harel Statecharts. He defined a pretty broad extension to typical state machines, with the goal of making state machines more useful for actual work with complicated systems.
A variant of Statecharts are build into Matlab now, as stateflow, which is an extension of simulink. Statesharts are also the basis of the UML "State Machine Diagrams".
Learn more about Stateflow in general at: https://www.mathworks.com/help/stateflow/examples.html
Stateflow has been updated for making it very easy to create state machines and flow charts in R2012b.
The major updates include a new graphical editor, state transition tables, MATLAB as the action language and an integrated debugger.
From the seminal 1999 book "Constructing the User Interface with Statecharts" by Ian Horrocks, published by Addison-Wesley (bold/italicized for emphasis):
From the very nature of user interfaces, it is apparent that states and events are a natural medium for describing their behaviour. Finite state machines are a formal mechanism for collecting and co-ordinating such fragments to form a whole. However, it is
generally agreed that, because of the large number of states and events organized in an
unstructured way, finite state machines are not appropriate for describing complex
systems. The feasibility of a state-based approach for specifying a user interface relies
on a specification language that results in diagrams that are concise, well structured,
modular and hierarchical.
There are many different notations used to represent finite state machines, such as state
transition diagrams and state transition matrices. However, such notations do not address
the fundamental problems associated with finite state machines. The statechart notation is
not just another notation for a finite state machine; statecharts are a major step forward for state-based notations. They provide a much richer and much more powerful specification
language than any finite stale machine notation. All the serious problems associated with
finite stale machines are solved by statecharts:
The number of states in a statechart rises in proportion to the complexity of the
system being specified. In finite state machines, the number of states tends to
increase rapidly with only a modest increase in the complexity of the system
being specified.
Statecharts avoid duplicate states and duplicate event arrows. This avoids large,
chaotic diagrams that are difficult to understand and difficult to modify.
The states in a statechart have a hierarchical structure, which means the system
being modelled can be considered at different levels of abstraction. The modular
nature of the states ensures that it is not necessary to understand an entire statechart in order to understand just one part of it. In a nutshell, statecharts are to
state transition diagrams what modular decomposition and abstraction are to
monolithic code