... | ... | @@ -5,17 +5,31 @@ |
|
|
- Transition notation: Starting at PDF page 371
|
|
|
- Trigger specification (including when/after/at): Starting at PDF page 333
|
|
|
|
|
|
# Usage Scenarios
|
|
|
The **state machine diagram** is used to illustrate the life-cycle of single objects and the behavior of operations within a software system.
|
|
|
This kind of diagram can be greatly used to get a detailed understanding of the behavior of objects, conditions and flows within the overall system.
|
|
|
For example, you can use it in the early design phase of a new software system to model the behavior of a specific component to describe its workflow. Especially, when the behavior of an object (lifecycle) or operation is not well understood yet.
|
|
|
# Introduction / Usage Scenarios
|
|
|
The **state machine diagram** is used to illustrate the lifecycle of single objects and the behavior of operations within a software system.
|
|
|
This graph-based diagram can be greatly used to get a detailed understanding of the behavior of objects, conditions and flows within the overall system.
|
|
|
For example, you can use it in the early design phase of a new software system to model the behavior of a specific component to describe its workflow.
|
|
|
Especially, when the behavior of an object (lifecycle) or operation is not well understood yet.
|
|
|
|
|
|
UML state diagrams use the following notations:
|
|
|
|
|
|
- *States* are denoted as rectangles with rounded corners and a name.
|
|
|
"A State models a situation in the execution [...] during which some invariant condition holds.
|
|
|
In most cases this condition is not explicitly defined, but is implied, usually through the name associated with the State." (UML Spec 2.5, S.348/306)
|
|
|
For example: "Ringing" or "Dialing" are common states when modeling the state machine for a telephone.
|
|
|
- *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*.
|
|
|
Altogether, *composite states* are used to show hierarchies of states and concurrent execution/behavior.
|
|
|
|
|
|
# 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).
|
|
|
|
|
|
# What is a State?
|
|
|
Consider a state as a specific position within the life-cycle or behavior of an object during runtime of an application.
|
|
|
Consider a state as a specific position within the lifecycle or behavior of an object during runtime of an application.
|
|
|
|
|
|
# Example Scenario
|
|
|
Assume that your customer wants you to develop a banking machine application called "ATM". It acts similar to general ATMs and thus allows to withdraw or to deposit cash. The application has two major states (Authentication or Withdrawal of Cash).
|
... | ... | |