Come al solito, non esiste una risposta definitiva per come devi modellare qualcosa. Tutto ciò che è valido in base a qualsiasi linguaggio di modellazione applicato è disponibile e può essere potenzialmente utilizzato in questo modo.
Detto questo, gli stati intermedi non sono niente fuori dall'ordinario. Devo anche correggere il commento fatto da @rwong, che uno stato rimane invariato in assenza di eventi di input. Questo non è assolutamente il caso. In particolare, lo standard UML definisce qualcosa chiamato transizione di completamento ( UML SSS 15.3.14 ), per cui la semantica è definita in modo tale da poter passare immediatamente allo stato successivo, dopo che lo stato di origine ha terminato la sua immissione e fare attività.
Quindi sì, gli stati intermedi possono essere modellati, e sì, esistono molte macchine a stati, che modellano gli stati intermedi. Tuttavia, se nel tuo scenario ha senso o meno, non è possibile rispondere facilmente.
Per rispondere alle tue domande: Sì, questi stati possono essere molto significativi, ma ciò è dovuto principalmente al comportamento che il tuo modello assegna loro. Se debbano essere modellati in modo esplicito, deve essere deciso su base statale. Se è insignificante e in realtà hai solo una transizione, allora potrebbe essere meglio non modellarla esplicitamente. È anche una chiamata di giudizio ogni volta, indipendentemente dal fatto che assegni un'azione alla transizione o utilizzi uno stato intermedio con una transizione di completamento. Una regola empirica qui è che è giustificato utilizzare uno stato esplicito, non appena si ha un comportamento abbastanza complesso ad esso collegato. Se si aumenta solo una variabile contatore, tuttavia, un'azione di transizione è facilmente sufficiente per modellarla. Per quanto riguarda il termine tecnico, penso che il concetto UML di transizione di completamento sembra essere la soluzione migliore per ciò che hai descritto.
Come nota a margine: nei tuoi esempi, hai diversi stati intermedi raggiungibili dopo lo stato inattivo , e in questo caso la modellazione degli stati intermedi esplicitamente mostra immediatamente un problema: come fai distinguere quale transizione usare? chiamare non è il tuo unico trigger in realtà, perché ciò significherebbe che il tuo stato di inattività ha almeno quattro transizioni attivate solo in base al richiamo , mentre dovresti avere condizioni di trigger mutuamente esclusive ( comprese le guardie) per le transizioni. Se non lo fai, la tua macchina di stato diventa non deterministica, che probabilmente non vorresti.
Suggerisco anche di leggere su macchine a stati in SSS UML per prendere confidenza con altri termini tipici relativi alle macchine a stati. A giudicare dalla loro assenza nel tuo post, immagino che potresti trarre profitto dal pensare alle differenze tra stati, transizioni, trigger, guardie, ecc.