Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: DanG83616 on October 02, 2010, 03:05:03 pm
-
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?
-
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.
-
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
-
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).
-
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
-
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)
-
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
-
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".
-
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?
-
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.
-
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.
-
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
-
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
-
This could all make perfect sense if Signal had attributes.
One small point: a Signal can indeed have attributes.
-
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
-
From EA's glossary in the help:
event
The specification of a significant occurrence that has a location in time and space. In the context of State diagrams, an event is an occurrence that can trigger a transition.
signal
The specification of an asynchronous stimulus communicated between instances. Signals can have parameters.
Trigger itself is not defined.
b.
-
What? Read the product documentation? How will I ever invent anything?
It would seem more straight forward to make Trigger and attribute of Transition. In that sense the Trigger attribute would be of type Event; it would be an instance of an Event. An Event, being a specification, would have sub classifications of Call, Signal, Change, and Time. Actually Call and Signal might be subclasses of Message. Call would map to a port with a provided interface and Signal would map to a port with a required interface.
I wonder if we could come up with a graphical syntax for representing this stuff. Oh, there I go inventing again. ;)
This discussion has helped and I think I'm ready to make a profile to codify the above. I still wonder why Sparx did what they did with the Trigger dialog. It implies some alternate rational than the above scheme reflects.
-
Dan
Did you read this topic in the Help? (Sorry, I know you want to be a Hoopy, Froody kind of guy, but just assume that the Help, too, begins with the words "Don't Panic".)
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/trigger_element.html
You can create Triggers as properties of Transition relationships, and they are of type CallEvent, SignalEvent, ChangeEvent or TimeEvent (although EA code gen for state machines currently only supports the last two).
You shall go to the ball. Sorry about the planet though.
-
Who doesn't strive to be a really hoopy frood?
The main thing that confused me is that a signal is treated as a separate thing from event. I now understand that a Trigger is an instance of an Event. A SignalEvent is a kind of Event whose instances are created by the occurrence of a Signal (as opposed to a call, change, or time) coming from a specific port or ports. The Signal gets its own spec.
Honestly, I don't think the Help would have cleared this up for me but what it says is accurate. Very often, the Help helpfully states things like: "Port -- Use this field to specify a port." Whew! Good thing I didn't try to put a Component in there...
Thanks,
Dan
-
I still didn't get it right in my last post. I left out the key point that KP and Geert both made about Trigger specifying Event/Behavior relation.
Events occur. Events may or may not cause Behavior. A Trigger specifies an Event/Behavior pair, plus optional Constraints.
Revisited this because of new comments in the LinkedIn UML Professionals group where I posed the same question.
Dan