Entering transitions in statecharts

[revdev]

A standard practice in MDA is to ensure that all events leading to a given state are the same.  It would be nice if, after creating a transition between 2 states, I could select a  trigger from a list and not create a new trigger (that shows up in the Project Browser) each subsequent time I use the trigger name.  The current way, I have to recreate the trigger each time I use it.

Any thoughts on how valid this request is?

[gpc]

Hi, Have you used the state chart editor - a cool tool, which gives the correct effect. Has some bugs, but overall very useful. Right-click on a state diagram, select "State Diagram Editor" then select one of the lower three options.

[mbc]

Hi revdev, I am completely with you on this issue!!! I have just been tearing my hair out over this problem.

Thanks gpc for your suggestion. The lower TWO options give the desired result (the third one suffers from the same weakness as the diagram editor). Anyway, in my opinion, the state-event table editor is a MAJOR step down from the diagram editor in ease of use. Finding the right states and events in the table is at least a thousand times harder than in a diagram.

I can only consider it a bug that the diagram editor creates duplicate triggers instead of letting you choose an existing one.

[mbc]

Just downloaded the latest build (build 818 ), and yes! The bug has been fixed!!! Hurray for Sparx!

I don't know exactly which build fixes it. I think I skipped about 10-15 builds.

Best regards,
Mikkel

[jeshaw2]

A standard practice in MDA is to ensure that all events leading to a given state are the same...  

Hoping to learn something new here.  Would you expand a bit on what you mean by this?  For example, I can think of many different events that put me in a happy state.

[revdev]

Just saw your question.  Since events can carry data and a state shouldn't have to know which event caused the transition, it is proper for the entry method to have just one event type to extract data from.  If there are different events with different data, then the target should (or at least could) be different states.  I would model your example with the GettingHappy event which causes transitions out of many states to the Happy state.

Regards

[jeshaw2]

RevDev;

Sorry, I can't say that I agree with your premise.  

Often, people think of a state as an entity that has encapsulated self awareness; that it has somehow been awakened like a sleeping giant, by an event (or more properly, and event occurrence) which then begins to process data carried by the event occurrence object. It is almost as if the state receives an event occurrence for processing.

I think of state as being condition that allows an object to execute certain state related behaviors.  Its the object, not the state, that recognizes the event occurrence and processes event occurrence related data.  The object has no trouble differentiating between various event types that occur and can decode the varying event data structures associated with them.


Regards
-Jim

[mbc]

I must agree with Jim here.

revdev wrote:

Since events can carry data and a state shouldn't have to know which event caused the transition, it is proper for the entry method to have just one event type to extract data from.

If the state (or entry method) doesn't know which event caused the transition, how can it extract data from it? Don't get me wrong, I agree that they shouldn't. My states don't receive data. Entry methods don't get data from events either, because they don't know about the events.

Actually, states getting data doesn't make much sense to me, because states don't DO anything. What would happen to the data?

The concept that I have, that uses data from events is actions. An action is specified for each transition - therefore it knows about the event.

Best regards,
Mikkel