Is there any tool, you could advice, for designing state machine or "protocol".
I mean small state-machine with 7-12 meaningful state (or x2 technical states - for example handshake can include several stages, but only 1 meaningful state), witch can be easily designed but hardly be supported/redesigned in necessary condition.
P.S.
I'm not close to "state machine theory", but in my practice protocol state machine has weaker "happens before" relation when common state machine"
Related
I am still new to SysML and UML and the simulation of those diagrams. I am using Cameo Systems Modeler 19.0.
Context: My problem concerns the continuous simulation of an activity diagram in which a state machine diagram is nested. In the activity diagram I have a Call Behaviour Action which calls the state machine diagram. After this call behaviour action there are other actions to be executed. When I simulate the activity diagram the simulation switches to the called state machine diagram without any problem. Also the simulation of this state machine diagram is fully functional.
Now onto my problem: When I finalize the simulation of the state machine diagram by choosing states, path and their triggers so that I get to the Final State Node, it terminates the simulation of the State Machine Diagram (as expected). But the simulation won't continue executing in the parenting activity diagram.
Am I doing something wrong? Are you not supposed to be able to simulate these kinds of diagrams nested like that? Am I expecting something of Cameo Systems Modeler, that this programm just can't do?
Thanks for your help! If my description is not sufficient, I will happily provide a .mdzip as a minimal example!
In UML and SysML state machines, reaching a termination pseudo state means that the scope to which the behaviour that is defined by the state machine is terminated (when it is on the top scope in the state machine diagram). This is treated in different tools diffently. Some tools use (by default or always) the state machines as mester for simulation and when the topmost state machine enters a termination pseudo state the simulation is stoped, even if it was triggered from an activity.
There is a further kind of end pseudo state for state machines, it is called an exit point. Exit points trigger that the current scope is left. And as you dont want to stop your simulation this is waht you could use. An exit point is denoted by a hallow circle with cross.
Thought: Plenty of tools deviate from whats defined in UML and SysML especially when simulating dynamic behaviours. So there might be some special options in Cameo that possibly need some consideration. One solution to some of the tools is that you create a master state machine, that triggers your master activity.
It definetely is a bug. I issued a problem and the support team identified it as such.
Update: it has been fixed
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).
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 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