uml/state-machine-diagram.md

@@ -26,15 +26,41 @@ Therefore, their execution may be interrupted.
 In contrast to *do* actions, *exit* actions are always completely executed.
 
 - *Transitions* are denoted with a solid line and an open arrow.
-As the name implies, they are used to define *state transitions*.
+As the name implies, they are used to define state transitions.
+They may be additionally denoted with a label in the form of `trigger[guard]/effect`.
+*Guards* are boolean expressions, which may secure that a *transition* is executed, e.g., "[time left]".
+*Effects* are actions, which may be performed if the *transition* is actually executed, e.g., "/go to cinema".
+*Triggers* are events, which initially cause the *transition* to be executed.
+If no *trigger* is stated, *transitions* are immediately executed upon exiting the state.
+There are different types of events for a *trigger*:
+  - *Call Events* are used "for messages requesting that a specific operation is called", e.g., "work" or "pause".
+  - *Signal Events* are used to show that a transition is triggered due to a receiving signal, e.g., "lecture started".
+  - *Change Events* are always denoted by "when" followed by a boolean expression.
+They are used to trigger a transition, if an attribute in the current state changed it's value, e.g., "when money < 0".
+  - *Time Events* are denoted with "after" followed by a time expression, e.g., "after 10 seconds" or "after lunch".
+Alternatively, *time events* may also express precise instances of time, e.g., "at Feb. 02, 2018".
+  - *Any Receive Events* are always denoted by a simple "all" and are used as fallback or else clause (transition).
 
 - *Composite states* are also denoted as rectangles with rounded corners and a name.
 They contain at least one *region*, i.e., a fragment that may execute concurrently with other *regions*.
 A single *region* in a composite state is not visible.
 Two or more *regions* are denoted by using dashed lines.
-These *regions* (or a single one) are then made up of nested *states* (called *substates*) and *transitions*.
+These *regions* (or a single one) are then made up of nested *states* (called *substates*) and *transitions* (both denoted as previously introduced and see example below).
 Altogether, *composite states* are used to show hierarchies of states and concurrent execution/behavior. 
 
+- *Initial pseudostates* constitute the entry points of the overall state machine or an embedded *region*.
+They are denoted with a small solid filled circle.
+At one level of hierarchy, there is at most one *initial pseudostate*.
+*Transitions* from the *initial pseudostate* are never (!) denoted with a *trigger* or *guard*.
+
+- *Final states* are denoted with a circle surrounding a small solid filled circle.
+One level of hierarchy (e.g. *region*) may contain any number of *final states*.
+The execution of the state machine level is finished, if a *final state* on the same level is reached.
+
+- *Terminate pseudostates* are denoted with a cross.
+One level of hierarchy (e.g. *region*) may contain any number of *terminate pseudostates*.
+The overall execution of the state machine is discontinued, if one *terminate pseudostates* at any level is reached.
+
 # Obligations for the lectures and the final exam in "Softwaretechnik" (Tips for Modeling)
 When creating a **state machine diagram**, remember that it must contain all necessary information (states, activities, actions, transitions, events, guards, and triggers). Otherwise this type of diagram is useless and can be thrown away. Especially for transitions between states it is important to specify the relevant triggers, guards, and behaviors.
 An example class diagram is shown in [Example State Machine Diagram](#an-example-state-machine-diagram-for-the-given-scenario).