Adding State Machines to TextUML and AlphaSimple [take 1]

I decided to go ahead and finally implement support for state machines in TextUML and AlphaSimple.

This is an example of what a state machine will look like (take 1), based on fig. 15.33 in the UML specification 2.4:


(...)
statemachine Phone

  initial state
    entry { self.startDialTone() }
    exit { self.stopDialTone() }
    transition on digit to PartialDial;

  state PartialDial
    transition on digit to PartialDial
    transition when { self.numberIsValid() } to Completed;

  final state Completed;

end;
(...)

A state machine may declare multiple states. Each state declares a number of transitions to other states. Each transition may be triggered by many events (or none), each denoted by the keyword ‘on’, and may optionally present a guard constraint (using the keyword ‘when’). The initial state is the only one that may remain unnamed. The final state cannot have outgoing transitions, but just like any other state, it may declare entry/exit behaviors.

What do you think? I did try to find existing textual notations for UML, like this and this, but none of those seem to be documented or look like covering all the UML features I want to support. Any other pointers?

EmailFacebookLinkedInGoogle+Twitter

6 thoughts on “Adding State Machines to TextUML and AlphaSimple [take 1]

  1. Andrew

    March 10, 2012 at 3:00am

    Just a couple of minor comments:
    - The initial state has the state keyword second, but the other two state starts with state. Maybe it could be “state Initial” at the start? I’m guessing there can only be one “state Completed” so that seems like it would fit.
    - When would the exit of the final state be called?

  2. rafael.chaves

    March 10, 2012 at 12:13pm

    Hi Andrew,

    The idea is that the “initial” and “final” keywords are modifiers, and as other modifiers in TextUML, they come before the thing being modified (in this case, a state). Other than that, final and initial states have the same syntax as any other state (they can have names as well):

    [<modifiers>] state [<name>] [<transitions>]

    But as you know, I am not attached to the current TextUML notation, and it is just one of many possible (I actually started implementing one way more “sugary” than TextUML but dropped that effort as working on a second notation at this point seemed wasteful). Any two textual notations over UML should be interchangable, as the abstract syntax and semantics are really the same (also, any existing models can be automatically converted to future, better notations).

    BTW, there can actually be many final states – each with their own entry/exit behaviours. You are right though that there can only be one initial state (and naming it has no actual effect in the behavior of the model, as no other state transition to it).

    Thanks for the feedback!

  3. Andrew

    March 11, 2012 at 9:52pm

    Ah, ok. On second look the syntax is quite clear, thanks for the clarifications.

  4. Daniel Rippa

    March 18, 2012 at 1:23pm

    Any chance of having a new TextUML version with StateMachines included soon?

    • rafael.chaves

      March 18, 2012 at 2:29pm

      Hi Daniel, thanks for your interest. I also thought the addition of state machines was a good excuse for a new release… but I am not sure the current set of features is complete enough even for a starting point.

      What level of support do you need?

Comments are closed.