| ... | ... | @@ -3,25 +3,25 @@ |
|
|
|
# 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.
|
|
|
|
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. Especially, when the behavior of an object (lifecycle) or operation is not well understood yet.
|
|
|
|
|
|
|
|
# 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.
|
|
|
|
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 events, guards, and triggers.
|
|
|
|
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.
|
|
|
|
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 has two major states (Authentication or Withdrawal of Cash).
|
|
|
|
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.
|
|
|
|
|
|
|
|
Possible results:
|
|
|
|
- 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 (abort of the machine).
|
|
|
|
- Option 3: correct (pin) -> change to state WithdrawCash
|
|
|
|
Possible results are:
|
|
|
|
- Option 1: incorrect (pin) and errorCounter < maxTries --> try again.
|
|
|
|
- Option 2: incorrect (pin) and errorCounter >= maxTries --> authentication failed, abort the machine.
|
|
|
|
- Option 3: correct (pin) --> change to Withdrawal
|
|
|
|
|
|
|
|
During the withdrawal, the user is able to choose between withdraw and deposit. In both cases he has to define an amount. Depending on the choice, either the specified amountis added to the account or, if the amount does not exceed the balance, substracted from the account. Afterwards the user is able to finish the transaction (abort of the machine).
|
|
|
|
During the withdrawal, the user is able to choose between withdraw and deposit. In both cases he has to define an amount. Depending on the choice, either the specified amount is added to the account or, if the amount does not exceed the balance, subtracted from the account. Afterwards the user is able to finish the transaction (abort of the machine).
|
|
|
|
|
|
|
|
## 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):
|
| ... | ... | @@ -30,6 +30,16 @@ The following figure shows an example UML state machine diagram, which reflects |
|
|
|
|
|
|
|
|
|
|
|
### Explanation
|
|
|
|
We model the states at first. ...
|
|
|
|
We model the states at first. We identify the two major states Authentication and WithdrawCash, and add two states Rejected, and Finished, in order to provide feedback for the user, instead of aborting the machine directly afterwards.
|
|
|
|
Additionally, there are two special states (initial state / start - circle completely filled in black, final state / stop - white circle with a black circle in the middle), which are used as an entry and exit for the overall machine. We included the identified states within a parent state ATM, which is started and aborted outside and communicates with the states within.
|
|
|
|
|
|
|
|
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 |
|
|
|
As described in the scenario, for the Authentication, we have three activities - starting with openLogin, performing checkPin, and finishing with closeLogin. These are modeled as entry, do, and, exit actions within the state. Afterwards, we take a look into the possible results for the pin entry and create the transitions between the states.
|
|
|
|
|
|
|
|
Possible results were:
|
|
|
|
- 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 (abort of the machine).
|
|
|
|
- Option 3: correct (pin) --> change to state WithdrawCash
|
|
|
|
|
|
|
|
Based on this options, we define corresponding transitions, which may lead from our starting state to a different state.
|
|
|
|
If we take option 1, we need to define a when-Event, which is triggered when the pin is incorrect and errorCounter < maxTries. The action increased the error counter and the user is able to try it again. Otherwise, if the pin is correct, we change the state to WithdrawCash.
|
|
|
|
Within this state, we have three options - withdraw, deposit, and finish. The transitions are handled in the same way as in the state Authentication, except for the usage of the guard [amount <= balance], which condition needs to be true, otherwise the transition is not executed. In case of a failed authentication, we change towards the Rejected state and may present the user and information about the rejection. The same applies for finishing the WithdrawCash state. Both states lead directly into the final state without any events or guards. |
|
|
\ No newline at end of file |
