State Machines, entry/exit actions and classes

[Vandermyer]

I have created a Class and then added a State Machine to this class. The states of the state machine represent the states that an instance of that class may be in.  If I now add an entry or exit Operation to a state the Operation element created is below the state it relates to. My problem is this: the states are states that an instance of the class may be in, so the operations (entry/exit actions) are common to the class.

There are several states that use the same entry/exit Operation, so how can I create entry/exit Operations for a state that are part of the class being designed, and make use of the fact that the state Operations are actually common operations of the class?

My solution at the moment is this: create entry/exit Operations for each state, and also create a similarly named Operation for the class, then for the various state operations define the Behaviour to be the required common class Operation. This can also be indicated on the diagram by checking the Show Behaviour in Diagram checkbox.

This seems a clumsy way to indicate what I want on a diagram and seems to be defining multiple operations to do the same thing. Is there a better, more elegant, way of doing what I want? Any suggestions?

[Geert Bellekens]

Dennis,

I think that is the only (correct) way of doing it.
Remember, all states are separate entities, and they don't inherit from some kind of abstract superstate, therefore you need to define the entry/action/exit actions for each state separately.
Linking the action to a common behavior is the best you can do.

Geert

PS. I do think it is a bit strange that you would have so many states using the same operation as an entry/exit action. That seems to indicate that the design is sub-optimal.

[Paul Lotz]

It's not entirely clear to me what you are doing, so I may repeat a bit of what you are actually doing.

For something like this we implement the state machine using the State Pattern.  For this we have a Context class (I think this would be your Class) and then states that we implement as state classes.  This means that each state class can define its own entry and exit methods [(e.g., Enabled:entry()].  Each method on a state class can invoke one or more methods on the Context* to carry out specific (atomic) tasks, in any desired arrangment.

*We actually break the Context class of the classic State Pattern into two pieces, Context and Model.  Context provides an interface to clients and contains a Model object.  Model provides an interface to the State methods.

[g.makulik]

It's not entirely clear to me what you are doing, so I may repeat a bit of what you are actually doing.

For something like this we implement the state machine using the State Pattern.  ...

I also think that this is the right approach for state machine implementation in an OO model. Unfortunately this isn't well supported using EA transformation and code generation. I'm currently working on an AddIn to have transformation support from UML State Machines to a State Pattern class model. This is supposed to generate a C++ class model that is interworking with my STTCL C++ template class framework (see http://makulik.github.com/sttcl/ for more information).
But may be it would be a good idea to have a 'simple' mode of this AddIn for transformation, that doesn't rely on any framework. This might have some minor deficiencies since certain aspects (e.g. orthogonal state concurrency) cannot be handled without certain features of a framework or OS.

Best regards,
Günther

[Eve]

The Operations for a state behavior are actually just behaviors. If you want them to have the same behavior then just make them call a common behavior. (The operation behavior tab allows you to do that)

[DanG83616]

Regarding the OP, your Behavior spec can use the Operations() available in the /context: BehavioredClassifier of the state machine.

Rant:
States do not have BehaviorFeatures, which is what Operations are; states only have Behaviors (exactly three roles: +entry, +exit, +doActivity). It is irritating the EA doesn't conform to the UML on this. The EA way to depict entry, exit, or doActivity, is to add an Operation to the State (which shouldn't be possible). Has anyone found a way to associate Behaviors to States?

An ugly fix is to create a tag for each collection and list the Behavior names. That gives me a way to actually specify the names of the behaviors and which role they play. Show the tags compartment to see them listed in the diagram. My transform will have to know to use the tag list rather than standard UML associations. There has to be a better way.

[DanG83616]

I just took a look at the xmi and it shows State::entry correctly typed as a Behavior and having an ownedOperation. That is legal because the ownedOperation association is inherited from Class. The Activity that defines my entry Behavior got placed into State::packagedElement but I cannot find where State inherits the packagedElement association.

If only State::entry had contained my Activity...