I'd be curious to know whether finite state machines that have conditional transitions can be expressed as Markov chains? If they can't, what would be a good counterexample?
A Markov Chain is a "recording" of a state machine where you have probablities between state changes. A UML state machine does not directly have these probablities. State transitions only have guards (and some other attributes). So in order to create a Markov Chain you need a profile which defines state transitions that also offer probabilities. Maybe (depends on your use case) you can simply use the guards to express these probabilities.
Related
As far as I know, UML state machines model the behavior of one element, for example the behavior of one class.
I wonder how to model state machines with two classes which interact.
The state of one class depends on the state of the other class and transition of one state machine may trigger transition of the other state machine.
Do I have to use UML effect? Could an UML effect of one state machine trigger a transition of another state machine?
You can send events between classes to trigger transitions, something like this, for example:
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.
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.
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
In UML, does an object's state machine define that object's lifecycle?
That is, do transitions from the initial state to an ordinary state create the object, and transitions to the final state dispose of that object?
Generally yes - at least that's probably the most common way of using them.
It's not mandated that way in the UML spec; it allows a more general use of state machines. For example, a Final State can be used to signify the end of a behaviour thread within a region if the state machine has >1 regions. Or a state machine can be used to define a protocol instead of an object's lifecycle.
Some variants (profiles) of UML do enforce the behaviour you describe, for example Executable UML.
I'd probably turn the question on its head and ask: would it be useful to you if the state machine did define the object's lifecycle? If so then just use it that way. If you need to formalise then you could define a profile. But it's equally fine to just agree informally in your team.
hth.