Reply To: Initial state

[Levi]

In xtUML, there is a rule that a class created by the “create” statement is initialized in the lowest numbered state (usually state 1). It is correct that the rest of the numbers have no bearing on ordering. Verifier and the C model compiler both adhere to this rule.

Creation transitions can be used to initialize an instance into any state. For example, a state machine for “class1” with 5 states could have a creation transition to state 2 assigned event “foo” and another creation transition to state 4 assigned to event “bar”. If the event “foo” is generated to “class1 creator”, the event dispatcher will create the instance and transition to state 2. Likewise if “bar” is generated, the instance will be created and immediately transition to state 4. Only for synchronous creation using the “create” statement is the lowest numbered state rule applied.

It should also be noted that with the “create” statement, the activity body of the lowest numbered state is not executed. Common patterns are to have an empty “initial” state for state 1, or to have a transition to self in state 1 that gets the lifecycle started.

We’ve actually had some good discussion recently on the xtUML community chat (“Community Chat!” link above) about this. Both of the patterns I described above are distasteful to me as they don’t seem to capture the essence of the model. I think it would be great if instead of using the “lowest number” rule, the semantics of the “create” statement are that the instance is created in an architecturally provided initial state similar to the non existent start state that is used for creation transitions. I think this would allow the model to be captured more accurately and still provide synchronous creation of instances.