Triggers, Events and Signals

[DanG83616]

I am confused about Triggers, Events and Signals. Is there a best practice relationship between the three? I could say they are synonyms. I could say that a Trigger is a relationship between an Event and a state transition. I could say that a Signal is a specialization of an Event. I'm missing why the benefit of that distinction. I cannot seem to get it out of my head that both are "occurrences" and don't understand why it helps to have two kinds of occurrence. What consequence should I expect if I ignore "Signal" and just use Event? What might make me regret that decision?

[beginner]

A signal has contents.
An event can send a signal.
A trigger is a transition from one state to another.

Roughly compressed from Superstructures.

I just noticed that in SS 2.0 04-10-02 there are quite a number of places where Event and Trigger have been replaced by each other. An indication that these terms were not defined so well in the beginning (and yet?).

b.

[Geert Bellekens]

A trigger is a transition from one state to another.

I don't fully agree with this definition.
A trigger "triggers" something. This something might be a transition, but it might trigger other stuff too.

Geert

[RoyC]

No - I think beginner is correct. He isn't saying that a trigger causes a transition, he is saying that a trigger is a transition, which is broadly true. Nothing happens until the trigger occurs, then the triggered event takes place. A bullet remains static until the trigger changes state from NotPulled to PulledRightBack, at which point a firing pin causes an explosion and the bullet gains velocity. (I guess you can analyse a process down to the atoms and beyond, but there is a point of no return somewhere up to which is stasis and beyond which is reaction).

[Geert Bellekens]

Roy,

No you are making things difficult by talking about the trigger that executes the state transition of a (gun) trigger.

But I still don't agree. The trigger and the transition are two separate things.

To quote from the UML specs:

13.3.31 Trigger (from Communications)
A trigger relates an event to a behavior that may affect an instance of the classifier.

A trigger specifies an event that may cause the execution of an associated behavior. An event is often ultimately caused
by the execution of an action, but need not be.

15.3.14 Transition (from BehaviorStateMachines)

A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound
transition, which takes the state machine from one state configuration to another, representing the complete response of
the state machine to an occurrence of an event of a particular type.

So if we look at the state behavior of a bullet with states "stationary" and "flying", pulling back the (gun) trigger will trigger the transition from "stationary" to "flying".
The transition itself may include things like  rapid burning of the black powder in the bullet, heating the barrel, and triggering the transition of the "loaded" state of the gun to the "unloaded" state.

To make the distinction even more clear, there can be many triggers for a transition. Another trigger might be that the gun is dropped on the floor, accidentally triggering that same transition.
Regardless of what triggered it, the transition will still include the same behavior.

Geert

[beginner]

13.3.1: "A triggers specifies an event", but what does "specify" mean? Describe? From my stomach I'd say "cause". When you look at the common sense "event" is something that happens (a happening, yeah!) and the "trigger" is the reason, initiation, or the like.

At least we can learn that a glossary is inevitable, even for OMG.

b.

<edit> 13.3.1 should read 13.3.31 (the citation from Geert)

[Geert Bellekens]

13.3.1: "A triggers specifies an event", but what does "specify" mean? Describe? From my stomach I'd say "cause". When you look at the common sense "event" is something that happens (a happening, yeah!) and the "trigger" is the reason, initiation, or the like.

At least we can learn that a glossary is inevitable, even for OMG.

b.

I'd say "define" rather then "cause". As in
"A trigger specifiesdefines the fact that an event that may cause the execution of an associated behavior"

Geert

[KP]

Events occur. Events may or may not cause Behavior. A Trigger specifies an Event/Behavior pair, plus optional Constraints.

So our Trigger specifies our Event (gun dropped on the floor), the resulting Behavior (gun fires a shot) and a number of Constraints (bullet in chamber, safety catch off, gun lands with sufficient force, etc).

In conversational English: "The gun being dropped on the floor may trigger a shot being fired".

[RoyC]

OK - I take the point. I'm also not going to stand around being pedantic whilst Neil is being so casual with loaded guns!

Does Dan understand the distinctions now?

[DanG83616]

Well, no. EA creates an Event icon for a Trigger element when I create a Trigger, T1, from the Transition properties dialog. EA gives the choice of defining the Trigger as a Signal, Call, Time or Change. Choosing Signal and using the browse feature leads to EA presenting Signal elements or giving me the chance to create a new one. If I do I get a new Signal element, S1, in the project browser. Now I will have a Trigger with an Event icon and a Signal with a cool looking electrostatic discharge zappening on it. The Trigger properties Trigger tab shows that the trigger is triggered by the Signal. So, I can specify what triggers the trigger that has an Event icon and triggers a state transition. What shall I do with the Signal that triggers a trigger that has an Event icon and triggers a state transition?

Ah, that goes back to beginner's stipulation that a Signal has a payload (but does not also carry with it the transfer of control that comes with a Call). Time and Change do not have payloads. This could all make perfect sense if Signal had attributes. Otherwise, I still wonder just what was the intended use (something I might like to take advantage of) for Signal in this context.

[beginner]

I would not so much look at what EA allows to do (which might/not be correct) but to what you want to express. So focus on the two main elements signal and event/trigger (personally I would not differentiate between those as even the UML editors seemed to have trouble with that). Now take what UML/SysML can give you to model these elements graphically and try to express whatever you mean. As an example: we model signals as simple classes with the stereotype <<signal>>.

b.

[Geert Bellekens]

I must admit that we also don't use the full even/trigger/transition construction as this would be way too much overhead for our purpose.

We like to track which operations are responsible for which state transitions. Iso implementing the whole trigger thing we added a tagged value to the transitions with name = "triggered by" and type RefGUID limited to operations.
This allows us to create the link between the transition and the operations that trigger it. (we add multiple tagged values with the same name, because tagged values of type "RefGUIDList" are not really user friendly).
Then my addin allows users to nagivate between transitions and operations by means of a right click on either of them.

Geert

[DanG83616]

I sometimes advise not to use a tool if you don't know what you would use it to do. However, I also sometimes find a tool that solves a problem I didn't know I had (ignorance is bliss).

EA sort of assumes the GoF state pattern for state machine impl. In that pattern it is really natural to use operations as the only means of triggering from the outside. This is also pretty consistent with thinking of state charts as the way to specify modal behavior of a class. The state machine is internal to the class and the class interface is the only means to trigger it from the outside. If an instance of a class is an active object then it can also use signals to attach itself to its environment. Time triggers are a specialization of that.

Ah ha! That must be it! How will my active object know which events it must register for if I don't explicitly include Signals in my model? I just might start using the expression.

The problem I didn't know I had: No way to easily see the external events that the state machine must monitor.

A solution I didn't know I needed: Use Signal elements to specify those events (and tags, perhaps, to enable generation of the code to register for them).

I hope this isn't a perverted use of the syntax...

Thank you for the discussion. If nothing else, I got to think more about state machines and gain a deeper understanding.

Cheers,
Dan

[Paul Lotz]

This could all make perfect sense if Signal had attributes.

One small point: a Signal can indeed have attributes.

[DanG83616]

Why, yes, you are right. The properties dialog doesn't give you access to attributes but F9 does. Now, it all makes sense.

Thanks again,
Dan