Я пытаюсь смоделировать приложение GUI с помощью диаграмм состояний , базовые c logi c:
У нас есть начальная композиция state S
, и при переходе состояний с S1
на S4
, timeout
или error
могут произойти события, которые переведут конечный автомат в состояние Alert
, в котором отобразится диалоговое окно с предупреждением.
Я делаю S
составным состоянием, чтобы края до и от Alert
были минимизированы.
Пользователь может либо выберите retry
, когда приложение находится в состоянии Alert
, или закройте приложение, или просто ничего не делая и ожидая тайм-аута.
Но среди S3
и S4
есть «переходные» состояния, что означает, что если в этих состояниях возникает ошибка, если пользователь выбирает retry
, , мы можем перезапустить только с S2
, а не S3
или S4
. Я создаю составное состояние S5
и использую механизм истории, чтобы реализовать enet эту функцию.
Этот подход не масштабируется, скажем, что если у нас есть больше вложенных состояний внутри S1
или S2
, и некоторые из них являются временными (невосстановимыми), иерархия будет go глубже и глубже, а целые диаграммы состояний станут беспорядочными. Есть ли какие-нибудь передовые практики для такого рода моделирования?
Код Plantuml для диаграммы:
@startuml demo
hide empty description
[*] --> S
state Alert
state S {
[*] --> S1
S1 --> S5
state S5 {
[*] --> S2
S2 --> S3
S3 --> S4
}
Alert --> [H]: retry
}
S --> Alert: timeout or error
Alert --> [*]: timeout or quit
@enduml