UML state machine: Difference between revisions

Revision as of 13:01, 16 September 2010

Revision as of 14:37, 19 October 2010

Line 31:

=== Basic UML state diagrams ===

UML preservepreserves the general form of the [[state diagram|traditional state diagrams]]. The UML state diagrams are [[State diagram#Directed graph|directed graphs]] in which nodes denote states and connectors denote state transitions. For example, Figure 1 shows a UML state diagram corresponding to the computer keyboard state machine. In UML, states are represented as rounded rectangles labeled with state names. The transitions, represented as arrows, are labeled with the triggering events followed optionally by the list of executed actions. The '''initial transition''' originates from the solid circle and specifies the default state when the system first begins. Every state diagram should have such a transition, which should not be labeled, since it is not triggered by an event. The initial transition can have associated actions.

[[Image:UML state machine Fig1.png|thumb|upright=3|center|Figure 1: UML state diagram representing the computer keyboard state machine]]

=== Events ===

In the most general terms, an '''event''' is an occurrence in time and space that has significance to the system. Strictly speaking, in the UML specification.,<ref name=UML2_2></ref> the term event refers to the type of occurrence rather than to any concrete instance of that occurrence</ref>. For example, Keystroke is an event for the keyboard, but each press of a key is not an event but a concrete instance of the Keystroke event. Another event of interest for the keyboard might be Power-on, but turning the power on tomorrow at 10:05:36 will be just an instance of the Power-on event.

An event can have associated '''parameters''', allowing the event instance to convey not only the occurrence of some interesting incident but also quantitative information regarding that occurrence. For example, the Keystroke event generated by pressing a key on a computer keyboard has associated parameters that convey the character scan code as well as the status of the Shift, Ctrl, and Alt keys.

An event instance outlives the instantaneous occurrence that generated it and might convey this occurrence to one or more state machines. Once generated, the event instance goes through a processing life cycle that can consist of up to three stages. First, the event instance is '''received''' when it is accepted and waiting for processing (e.g., it is placed on the [[Message queue|event queue]]). Later, the event instance is '''dispatched''' to the state machine, at which point it becomes the current event. Finally, it is '''consumed''' when the state machine finishes processing the event instance. A consumed event instance is no longer available for processing.

=== States ===

Line 190:

=== Internal transitions ===

Very commonly, an event causes only some internal actions to execute but does not lead to a change of state (state transition). In this case, all actions executed comprise the '''internal transition'''. For example, when you type on your keyboard, it responds by generating different character codes. However, unless you hit the Caps Lock key, the state of the keyboard does not change (no state transition occurs). In UML, this situation should be modeled with internal transitions, as shown in Figure 6. The UML notation for internal transitions follows the general syntax used for exit (or entry) actions, except instead of the word entry (or exit) the internal transition is labeled with the triggering event (e.g., see the internal transition triggered by the ANY_KEY event in Figure 6).

[[Image:UML state machine Fig6.png|thumb|upright=3|center|Figure 6: UML state diagram of the keyboard state machine with internal transitions]]

Line 239:

Nevertheless, most of the statecharts semantics are heavily biased toward graphical notation. For example, state diagrams poorly represent the sequence of processing, be it order of evaluation of [[#Guard conditions|guards]] or order of dispatching events to [[#Orthogonal regions|orthogonal regions]]. The UML specification sidesteps these problems by putting the burden on the designer not to rely on any particular sequencing. But, when you actually implement UML state machines, you will always have full control over the order of execution, so the restrictions imposed by UML semantics will be unnecessarily restrictive. Similarly, statechart diagrams require a lot of plumbing gear (pseudostates, like joins, forks, junctions, choicepoints, etc.) to represent the flow of control graphically. These elements are essentially the old [[flowchart]] in disguise, which structured programming techniques proved far less significant a long time ago. In other words, these elements of the graphical notation do not add much value in representing flow of control as compared to plain [[Structured programming|structured code]].

The UML notation and semantics are really geared toward computerized [[UML tools]]. A UML state machine, as represented in a tool, is a not just the state diagram, but rather a mixture of graphical and textual representation that precisely captures both the state topology and the actions. The users of the tool can get several complementary views of the same state machine, both visual and textual, whereas the generated code is just one of the many available views.

== References ==