dimanche 21 juin 2020

How to properly model alert dialog with statecharts (hierarchical state machine)?

I am trying to model a GUI app with statecharts, the basic logic is:

  1. We have a initial composite state S, and when states transitioning from S1 to S4, timeout or error events could occurs, which will make the state machine transition into an Alert state, which will display an alert dialog.

  2. I make S an composite state so that the edges to and from Alert will be minimized.

  3. The user can either choose to retry when the app in Alert state, or close the app, or just doing nothing and waiting for timeout.

  4. But among S3 and S4 are "transient" states, which means if error occurs in theses states, if the user choose to retry, we can only restart from S2, rather than S3 or S4. I make a composite state S5 and use the history mechanism to implmenet this feature.

This approach doesn't scale, say, what if we have more nested states inside S1 or S2, and some of them are transient(non recoverable), the hierarchy will go deeper and deeper and the whole statecharts will become messy. Are there any best practices for this kind of modeling?

Plantuml code for the diagram:

@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

Aucun commentaire:

Enregistrer un commentaire