|
|
|
czi |
|
|
\ No newline at end of file |
|
|
|
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page ...)
|
|
|
|
|
|
|
|
# Usage Scenarios
|
|
|
|
The **state machine diagram** is used to illustrate the life-cycle of 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 it's workflow.
|
|
|
|
|
|
|
|
# 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, transitions, triggers, guards, and actions). 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 actions.
|
|
|
|
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.
|
|
|
|
|
|
|
|
# Example Scenario
|
|
|
|
Assume that your customer wants you to develop an banking machine application called "ATM" which acts similar to general ATMs, which allow to withdraw or deposit cash. The application can be in four different states (Authentication, WithdrawCash, Rejected, or Finished).
|
|
|
|
The application starts with Authentication, presents a login screen (openLogin), continues by allowing the user to enter a pin, which is checked afterwards (checkPin), and closes the login screen at the end (closeLogin). Depending on the result of the check (correct or incorrect), the number of unsuccessful tries (errorCounter), and the number of maximum tires (maxTries) the machine may change it's state to another state.
|
|
|
|
|
|
|
|
- Option 1: incorrect (pin) and errorCounter < maxTries -> try again, no state change.
|
|
|
|
- Option 2: incorrect (pin) and errorCounter >= maxTries -> authentication failed, change to state Rejected.
|
|
|
|
- Option 3: correct (pin) -> change to state WithdrawCash
|
|
|
|
|
|
|
|
## An Example Class Diagram for the given Scenario
|
|
|
|
The following figure shows an example UML state machine diagram, which reflects the requirements mentioned in [Example Scenario](#example-scenario):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Explanation
|
|
|
|
We model the states at first.
|
|
|
|
|
|
|
|
Additionally, there are two special states (start - circle completely filled in black, stop - white circle with a black circle in the middle), which are used as an entry and exit for the overall machine. |
|
|
\ No newline at end of file |
