Talk:UML state machine

This article is rated C-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool because one or more other projects use this class. Please ensure the assessment is correct before removing the `\|auto=` parameter.

Systems Mid‑importance

	Systems science portal This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is within the field of Software engineering.

This article

This article attempts to describe UML state machines as they are used in software, as people looking for the term "UML state machine" most likely will have software applications in mind. The related article about Finite State Machines is necessarily much more general, as it describe FSMs for any applications, from hardware through mathematics.

UML has a very rich semantics and notation for describing state machines; too rich, in fact, to cover completely in a Wikipedia article. In fact, it is one of the most complete state machine formalism every gathered into a single notation. This article is just a start to define the arguably most important concepts, notation, and semantics, to convey at least the general ideas incorporated into UML state machine formalism.

This article is divided into two main sections: "Basic State Machine Concepts" and "UML Extensions to the Traditional FSM Formalism". Time permitting I would still like to add a section about implementing UML state machines. This section would discuss automatic code generation as well as manual coding techniques and patterns.

Mirosamek (talk) 21:50, 12 August 2009 (UTC)[reply]

Some of the text in this article was previously published in http://www.embedded.com/215801043. Are you sure you're able to license this material for Wikipedia? Melchoir (talk) 02:15, 13 August 2009 (UTC)[reply]

Yes, I am the original author of the article published in http://www.embedded.com/215801043 and I hold all the copyrights to this work. I am also the author of the referenced book Practical UML Statecharts in C/C++ and I hold the copyrights to that work as well. Some of the contributed material was adapted from Chapter 2 of this book. Mirosamek (talk) 15:15, 13 August 2009 (UTC)[reply]

Hi, Miro Samek. I very much appreciate this (new) comprehensive article. I personally would be very much interested in (maybe not how to implement UML state machines) but how UML state machines diagrams are implemented and used. At the moment I also think the introduction is to technical for the general audience here. This is why a added a {{technical}} tag (for now). An extra overview section, and maybe a short history section could help. I think you could even mention some of the things you already mention here... And one other: images are mostly uploaded in Wikicommons. I can move them there, but you can do it yourself (just use the same names, and the files here will be automatically removed in a while). If you have any questions please let me know. And thanks again for your work. -- Marcel Douwe Dekker (talk) 20:29, 2 September 2009 (UTC)[reply]

guard condition evaluation order in HSM

am i to understand correctly that in going from a nested state to another nested state, you only evaluate the guard condition of the final state, and ignore all guard conditions of the transitive states (i.e. of super-states in the destination but not the source)? i would think that it would be more logical/practical to test all guard conditions not common to the source state, esp. given that you are executing all entry actions not common to the source state. Kevin Baas^talk 00:38, 12 January 2010 (UTC)[reply]

wrong arrows in sample images / diagrams

The sample images for UML state diagrams do not use the correct UML 2 arrows. Dunno if those were correct prior to 2.0, but 2.0 specifies them differently (not filled arrow-tip, should be like →). --Kissaki (talk) 17:52, 29 September 2010 (UTC)[reply]

Missing OCL

OCL is an abstract language for notating constraints. From it, also, via transformation, concrete language implementations can be extracted. Personally, I believe that most UML modelers support OCL when it comes to specifying state on entry/exit a/o transition entry/exit behaviour. What do you think? And, can we please point out to the user the ability to use OCL instead of informal natural language? —Preceding unsigned comment added by 91.54.30.197 (talk) 21:35, 26 October 2010 (UTC)[reply]

"However, the notation of UML statecharts is not purely visual. Any nontrivial state machine requires a large amount of textual information (e.g., the specification of actions and guards). The exact syntax of action and guard expressions isn’t defined in the UML specification, so many people use either structured English or, more formally, expressions in an implementation language such as C, C++, or Java.[10] In practice, this means that UML statechart notation depends heavily on the specific programming language." - definitely missing OCL, which is a core part of UML 2. --Amogorkon (talk) 11:19, 29 March 2015 (UTC)[reply]

Local Transitions in UML V2.3

In UML V2.3, the following statement is made with respect to Local Transitions:

Transitions of kind local will be on the inside of the frame of the composite state, leaving the border of the composite state, or one of its entry points, and end at a vertex inside the composite state. In the case of a local self transition, the target may be the source state itself, or an exit point on the source state.

This statement implies that the second example in Figure 8 is invalid, as the transition neither ends at a vertex inside the composite state nor at the composite state itself.

JPM Figure 15.47 shows a transition from an entry point back to the border of the composite state. Therefore, we should interpret "end at a vertex inside" to include the composite state itself. But, the second example is wrong because it does not originate from the border of the composite state or one of its entry points. —Preceding undated comment added 19:48, 15 February 2011 (UTC).

The UML V2.3 specification is also vague as to the exact behavior of a local self transition. According the Section 15.3.15:

kind=local implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered.

Unfortunately this statement is ambiguous, depending on the structure of the statemachine, and further guidance is not supplied. For example, consider an internal transition to a substate. The execution intent in this case is fairly obvious; exit all substates and enter the target state (including any parent states that must be entered). However, when considering a local self transition, after exiting the substates, which substates should subsequently be entered? Should the behavior mimic a deep history state, re-entering the previously active states? Or, should the local self transition source state enter its substates, as if it was initially entering the state (just not performing its own entry actions)? In order to avoid these types of ambiguities in behavior, one might consider refactoring a state machine to avoid the local self transition. It is possible to explicitely define the desired behavior by using local transitions to existing or new substates, thus avoiding local self transition usage altogether.

--Muebel (talk) 22:02, 18 December 2010 (UTC)[reply]

"Leaf state" terminology introduced without definition.

While reading the article, I came across the phrase "leaf state". It was not immediately apparent to me what this meant and I had to use a search engine to find this out. I believe that it is the same thing as "simple state", which is a phrase introduced in the article to describe a state with no substates. —Preceding unsigned comment added by 58.28.72.130 (talk) 22:39, 24 February 2011 (UTC)[reply]

Technical?

Unless someone steps forward to state in specific terms which aspects of this article are "too technical" I'm in favour of removing the imprecation to nowhere. As I read it, the text is making strenuous efforts to communicate a complex subject. — MaxEnt 22:08, 1 April 2011 (UTC)[reply]

Agreed. I'm removing them. --Aflafla1 (talk) 12:07, 8 September 2011 (UTC)[reply]

Scary Spaghetti

There are lots of uses of "spaghetti code" with the scare quotes, and I think the reason those quotes are there is that it is entirely subjective. The quotes act to protect the sloppy language from being called incorrect; it isn't incorrect only because it is phrased as opinion. It is a standard writing device, but I don't think it is appropriate here. In the sort of use as it is used here, it is mainly a pejorative used to describe code that is of subjectively low quality in specific ways. However, the actual cases here are generalized; there is no bad code to point to, and indeed, it is used to discuss the pros and cons of the UML State Machine as compared to other structures and methods. Therefore, it would be much more appropriate to use only the formal, non-pejorative names of other structures and methods instead of "spaghetti code." "Spaghetti code" is not an actual method or structure, except in the very primitive context of code that doesn't have any sort of structure at all. In the context of the article, the most primitive applicable situation would be firmware for a microcontroller, but "nobody" writes that in real, objective "spaghetti code." To be "spaghetti" in an objective way, it would have to be non-structured. (see Structured programming) Yet here, anything using if/else instead of state machines is called spaghetti; but using if/else heavily means it is likely Structured Programming of some sort, even if the author believes it is often done poorly. It should be clear after reading Structured Programming that every single use of "spaghetti code" in this article is mistaken.

Additionally, as discussed at [Structured programming] state machines can be implemented using unstructured code (jumping to the new state) in which case it would be both a state machine, and "spaghetti code," so even if you don't mind the subjective scare quotes, it is still objectively incorrect in context.76.105.216.34 (talk) 21:58, 24 January 2015 (UTC)[reply]

Wrong UML state machine diagram of a calculator

MarquisBs (talk) 20:26, 10 June 2015 (UTC)[reply]

The example of the calculators statediagram is acctually wrong:
Your normally beginning by entering a number where as here this is not the case.

Your doing this szenario:
1. Start calculator
2. Enter an operand
3. Enter the first number
4. Solving the calculation (which is not complete at this state and will fail)
5. Enter any number to get to the beginning state again
And this happens every time you start your calculator or pressing the "C"-button.

Therefore the changes to be made are: An additional state numberEntered between operand1 and opEntered. You get to number1Entered by entering any number (no dot here). Also you would draw a loop at number1Entered by entering another number or dot to create larger values than 9.

Additional: Also this calculator has no option to create bigger numbers than 9 because the transition to "operand2" from "opEntered" begins when hitting any number key or a dot. You need a loop at operand2 when entering any number or '.'

Renaming of states: I would suggest that you rename "operand1" to "newCalculation" because this is the point where you´re doing so. Also I would rename "operand2" to be "number2Entered" Normally you name a state after the transition actions or something that results out of an action. — Preceding unsigned comment added by MarquisBs (talk • contribs) 20:14, 10 June 2015 (UTC)[reply]

Software Used for the state charts

Hi,

Could someone tell me which software was used to generate the charts in this article?

Regards

'OR' use in 'Orthogonal regions' paragraph.

Some terminology in the first paragraph seems not correct to me. 1/ 'exclusive-OR'. In logic, applying this operator between multiple operands allows for an uneven operands to be true. For example A XOR B XOR C allows for B and C to be true at the same time. I do not think this is what is meant in the first paragraph. 2/ The second sentence uses the construction: 'either' 'OR'. OR should not be in uppercase (implying a logical or) as it is clear that the first paragraph wants to convey the message that only one of the substates is true at the same time. 'OR' is therefore to be understood as the 'or' in the common English construction 'either or'. 'OR' should be in lower case. BartYgor (talk) 11:11, 29 November 2023 (UTC)[reply]