State entry, exit, do action blocks.

[cpns]

I note that in EA state entry, exit, and do action blocks are represented as 'operations' on a state. Personally I find that somewhat strange, but am primarily concerned by the fact that the implementation prevents these from behaving like transition event/action blocks. For example, there is no field in which to place a guard.

It appears to preclude having an an action that is not an operation. So for example if I wanted:

entry[y==0]/x=0

I have to place "entry[y==0]" in the "Action" and "x=0" in the "Name".

Also EA does not represent these in an "Internal activities compartment" as defined in UML Superstructure Specification, v2.1.1 p552.

Neither does it have a "Internal transition compartment". In fact internal transitions also have to be added as operations, with bizarrely the trigger entered in the "Action" field and the action in the "Name" field.

• Am I missing or misunderstanding something?
  
• Is there anything wrong with my work-around?
  
• Is there a better work-around?
  
• Why are these features not implemented like transitions rather than operations?
  

An odd consequence of these being operations is that you declare parameters, when typically you would want to pass arguments - i.e. actual values - to some owning class's operation rather than an operation defined on the state... Wouldn't you?

Clifford

[Kevin G. Watson]

entry, exit these are always called on exit and entry... irrespective of the transistion...

the guard condition is on the transistion... it follows that if the transistion guard is met then the state exit op, followed by the transistion op and thenthe entry 9of the new state) op is executed in that oder...

Little confussed as to what guard you might apply to a do?

You seem to be using guard conditions to select transistions, which belong with sub-states

Kevin

[cpns]

Thanks Kevin, although you have not really told me anything I don't know or directly answered my questions. Perhaps I over complicted it. It is not that I am not aware of work-arounds or alternative ways of representing the semantics. I am merely trying to understand EA's implementation of "Internal activities compartment" and "Internal transition compartment". In EA they are operations, in UML they are essentially event/action blocks. The issue arises primarily from the fact that I have legacy models in a different tool, which implements them as I have described, and in which I have models that use this notation.

The problem with having the guard on the transition is that if the guard is to be applied to all incoming transitions or all outgoing transitions it would make more sense to apply it to the entry or exit events respectively. Which is after all how entry/exit are often used - to reduce repetition on transitions by collecting common actions - the guard condition may equally be common to all transitions.

I would understand the operation approach if the available operations were members of the class or object in which the state machine were contained - but even that obvious linkage is not available. It seems that it achieves very little other than to restrict valid UML notation.

Clifford