[State machines] Better integration with classes, and more consistency in how triggers/actions are managed

[ebousse]

Is your feature request related to a problem?

A rather widespread use of UML state machines is to define the behavior of instances of UML classes. In particular, a class may have operations that can be called on instances of said class. When designing the state machine of a given class, such calls can at least play two roles:

• When an operation is called (eg. by another object), this call is considered as an event that may trigger transitions in the state machine of the instance. In fact, a common way to design a state machine is to consider that most events are of this category.
• In addition, during the execution of the state machine of a given instance, the state machine may also make inner callers to services of said instance. This can happen in the behavior expression part of a transition, or in the Entry/Do/Exit clauses of a given state.

Typical example where operations are used both as triggers and behavior expressions:

In Gaphor, there is currently no "first-class" support for either of these cases.

Describe the solution you'd like

Let's consider that I prepare in Gaphor a class element, and that I put a state machine element inside this class, which I consider to be the behavior of instances of said class.

I then open the state machine diagram, and here is what I think would be useful:

• When creating/selecting a state:
  • The already existing Entry/Exit/Do fields could, in their drop-down lists, include the operations of the parent class (eg. a, b, c, foo, bar in the above example).
• When creating/selecting a transition:
  • The already existing trigger field, instead of a regular text input, could be a drop-down list showing all operations of the class (eg. again a, b, c, foo, bar in the above example), and allow to pick one of this list. This would better aligned with the Entry/Exit/Do fields.
  • A new field called "behavior expression" (term from the UML specification) where again a drop-down list could present possible operations to call during the transition (eg. again a, b, c, foo, bar in the above example). Again, this would better aligned with the Entry/Exit/Do fields, and with the proposal for the trigger field above.

Yet I understand this could be seen as slightly restrictive if all these fields were only drop-down lists. If possible, I believe the best of two worlds would be to allow either writing text without constraint, or to choose from a drop down list.

Describe alternatives you've considered

If we leave aside "first-class" integration between states and classes for now, a nice intermediate step could be:

• To provide a new behavior expression field on transitions, as a regular text field.
• To allow Entry/Exit/Do fields to be regular text fields.

This would at least make the use case described in my intro possible with meticulous and consistent use of all fields.