Как правильно смоделировать диалог предупреждений с помощью диаграмм состояний (иерархический конечный автомат)? - PullRequest
0 голосов
/ 21 июня 2020

Я пытаюсь смоделировать приложение GUI с помощью диаграмм состояний , базовые c logi c:

  1. У нас есть начальная композиция state S, и при переходе состояний с S1 на S4, timeout или error могут произойти события, которые переведут конечный автомат в состояние Alert, в котором отобразится диалоговое окно с предупреждением.

  2. Я делаю S составным состоянием, чтобы края до и от Alert были минимизированы.

  3. Пользователь может либо выберите retry, когда приложение находится в состоянии Alert, или закройте приложение, или просто ничего не делая и ожидая тайм-аута.

  4. Но среди 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
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...