Triggering events should be avail to all children

[kenty]

The exact same triggering events are repeated in the statechart diagrams in EA Model.  For example, I have a "poll" triggering event that is used heavily in my model as a triggering event for transitions in different part of the model.  My model is a complicated model with many substate machines and concurrent regions.  However, within each substate machine, this "poll" triggering event is created as its own SendSignalAction.  This is the SAME event in the system created MULTIPLE times.  These should be created ONCE in the parent hierarchy and available to all children substates because the same event is triggering transitions throughout the entire system.  The SendSignalActions should also be usable by any state transitions even if it is dragged from a child substate machine into a higher parent substate machine.

[jeshaw2]

Is there a question in here somewhere?  :-/

[kenty]

The questions are: why does EA Model not do this and should it do this the way I have outlined.

[jeshaw2]

Let's take this in pieces for better understanding...

The exact same triggering events are repeated in the statechart diagrams in EA Model.

What makes them "exact"?  How can the "exact" same thing be in more than one place at a time?  By what method are they cloned?  I assume you have declared them as a signaling action in the various locations yourself?

 For example, I have a "poll" triggering event that is used heavily in my model as a triggering event for transitions in different part of the model.

Used in what way?  Is the poll event signaled in all of these places?  What do you mean by the term "used"?  Do you mean "signaled" or "received"?

 My model is a complicated model with many substate machines and concurrent regions.  However, within each substate machine, this "poll" triggering event is created as its own SendSignalAction.  

Created by whom?  If my understanding of the above is correct,  each of the "poll" triggers are in a different namespace?

This is the SAME event in the system created MULTIPLE times.

Created by whom?  How would EA know that if they are in different name spaces?

These should be created ONCE in the parent hierarchy and available to all children substates

So you are asserting that substates inherit from parent states in a manner similar to class inheritance?  If you are saying  they should be created once in the parent, why haven't you done that?

because the same event is triggering transitions throughout the entire system.

Awaiting clarification of the above

 The SendSignalActions should also be usable by any state transitions even if it is dragged from a child substate machine into a higher parent substate machine.

 I'll deal with this later after getting clarification of the above issues.

Increased use of proper nouns would be helpful to me.

[kenty]

What makes them "exact"?  How can the "exact" same thing be in more than one place at a time?  By what method are they cloned?  I assume you have declared them as a signaling action in the various locations yourself?

OK, I'll make a clearer example.  Lets say I have a submachine state A that is part of a bigger statemachine.  This submachine state A has multiple concurrent regions A1 and A2.  Each of these has a submachine state.  The submachine states in each of these regions all respond to a "poll" triggering event.  They are concurrent regions because they are different subsystems.  Now, when this "poll" triggering event is created in the submachine state A's namespace, it is unreachable in concurrent region A1 and A2.  If I create the "poll" triggering event in the submachine states in the concurrent region, they are two different triggering events.  I can drag them "up" into submachine state A's namespace, but they are still different triggering events.  They are technically the same event but have different "instances".

Even if we did not have concurrent regions, if we have a triggering event named "poll" within a statechart, then all state transitions that are triggered by a "poll" triggering event should reference the same triggering event.  There is no reason why they should be different.

Used in what way?  Is the poll event signaled in all of these places?  What do you mean by the term "used"?  Do you mean "signaled" or "received"?

When I used the term "used", I meant that the triggering event was the trigger for a state transition (e.g. event[]/action).  Does it matter if the "poll" triggering event is signalled in all of these places?  Some subsystems in a concurrent region do not care about the "poll" triggering event and therefore do not have a state transition with the "poll" triggering event.  They therefore ignore it.

Created by whom?  If my understanding of the above is correct,  each of the "poll" triggers are in a different namespace?

This is the problem.  Should the triggering event's in a higher "namespace" be available in children "namespace"?  I say they should be available to all children "namespaces".

Created by whom?  How would EA know that if they are in different name spaces?

Namespaces should only prevent access to triggering events from different sibling branches, but not prevent access to triggering events from parents.

So you are asserting that substates inherit from parent states in a manner similar to class inheritance?  If you are saying  they should be created once in the parent, why haven't you done that?

There is no suggestion of "inheritence".  Tried creating triggering events in the parent, it doesn't work.  Triggering events created in a higher namespace do not appear in the triggering event list in a state transition specification in children namespaces.

[jeshaw2]

Lets try a different approach to this and see if it helps.

First off, the terms parent, sibling, child states are confusing to me as there are no generalization/specialization relationships involved in statemachines.  If, in your diagram, states A and B are nested in state C, then state C (according to Harel) is an abstraction of the paired states A and B, not a generalization of them.

I suspect your sibling and/or child states are actually Harel's orStates.  In the above example, if an object is in state C, then it must be in either state A or B, but not both.

I also suspect your state compartments are Harel's andStates.  If state M has compartments 1 and 2, then, if the object is in state M, it must be in both states M1 and M2 at the same time, giving rise to concurrency.

In a fashion reminiscent of Structured Programming, andStates and orStates may be nested within each other to any level of sanity.

Next we note that all statemachines are defined fully in the context of an object; each state being defined as a specific combination of the object's slot values (or range of values).  Composite objects most frequently give rise to andStates; the compartments being defined along the lines of its component objects.

We may now say: any event that the object is capable of sensing or signaling, is available to the whole object regardless of its current state at the time of the event's occurrence.  We also note that a given event may be signaled by one or more processes, they are not specific to only one process.  An example might be a divide by zero event.  

Some events are so significant that nothing special is required to detect them.  A diesel engine of a rail road train, crashing though your living room as you watch TV might be such an event.  Other events are more subtle (like ones spouse quietly falling into an emotional depression) requiring one to pro-actively listen (subscribe) for them.

Finally, at the CIM and PIM level of modeling, all objects are capable of sensing any event in the known Universe.  This is because events are broadcast, not directed communications from one object to another.  A major benefit of the statemachine concept is that one may specify the states in which an object will, or will not, respond to a specific event, if it responds to any at all.

If we are in agreement with all of this so far, can you express your question or concern in this context?  I suspect we are in agreement, but you perceive that somehow EA does not conform to this in some way?

[kenty]

First off, the terms parent, sibling, child states are confusing to me as there are no generalization/specialization relationships involved in statemachines.  If, in your diagram, states A and B are nested in state C, then state C (according to Harel) is an abstraction of the paired states A and B, not a generalization of them.

Sorry, we got mixed up about child/sibling/parent relationship.  The usage of those terms is made in reference to how the state "ownership" relationships are ordered in EA in the Project Browser.  See the image below:



OK, I should have uploaded this image ages ago.  The problem that I have is that I feel that "TriggeringEventC" should be the same for the entire statemachine.  However, you cannot have substate machines access SendSignalAction that are in "parent" namespaces.  In this case TriggeringEventC exists in the State2 namespace AND the overall statemachine namespace.  Since I intended them to be the same triggering event, I cannot see why they cannot be the same SendSignalAction.

I hope this clears this up.

[jeshaw2]

Well, this is certainly a "horse of a different color".  I cannot speak with any authority on EA, there are others here in the forum better qualified than I.

However, I think your concern is more with with EA's unique interface than its interpretation of the UML2.1.  From what I can determine, the project browser is more concerned with the arrangement and distribution of UML diagramming elements than it is with the true anatomy and structural topology of an object.

I'll leave it to others wiser than I to continue with this thread.  Sorry I can not  be of more help.

[kenty]

Well, this is certainly a "horse of a different color".  I cannot speak with any authority on EA, there are others here in the forum better qualified than I.

However, I think your concern is more with with EA's unique interface than its interpretation of the UML2.1.  From what I can determine, the project browser is more concerned with the arrangement and distribution of UML diagramming elements than it is with the true anatomy and structural topology of an object.

I'll leave it to others wiser than I to continue with this thread.  Sorry I can not  be of more help.

This is about their intepretation of the UML specification and their intepretations of statecharts and not about their user interface.  The reason being that both TriggeringEventC SendSignalAction are different entities that is not common to the entire model.  In theory they should be exactly the same but in reality they are TriggeringEventC and State2.TriggeringEventC.  This makes traceability and triggering event usage problematic.

I know they are different because when I set a note on one of them, it is not reflected in the other.  This is because EA stores them as separate SendSignalAction in the database.  They should really be stored in the "parent" nodes (look at the diagram, I'm talking about the tree that the elements are stored in) and be made available to "children" nodes.  They should be "propagated" up if another "sibling" branch or parent branch should use the triggering events.  This would mean global triggering events would propagate upwards to the root node and be available to "children" nodes.

There are benefits to this approach.  For one, you are not repeating yourself.  Remember one of the basic principles of good coding, do not copy and paste.  Surely this applies to design and modelling.  Second, you will be able to have an inventory of events that affect the model in the correct place in the hierarchy of nodes.  Lastly, because of the above, it would make automation tasks a lot easier.

[jeshaw2]

To my mind, the project browser is an EA interface!  

Looking at the browser contents in relation to other diagrams totally mystifies me if I think of it in terms of a system's topology (how its parts are interconnected).  It only make sense to me if I think of TriggeringEventC to be the name of a diagramming elemet which is located somewhere on a diagram and that such diagramming elements may have the same name as other such elements; ie, element names need not be unique.

In the UML, the term trigger refers to the type of an event (divide by zero for example) and not to a specific occurance of such an event ( 4/0, 18/0, etc.).  
As I said earlier, a given event type (such as that referred to by you as TriggeringEventC) can occur in many places in the logic of the system.  Transitions are triggered by event types, not specific events.  

Can it be that the browser is keeping track of the many places where an event of type TirggeringEventC is being raised and your issue with EA is that it is failing to optimize your use of the SendSignal operation?  I don't think the optimization is possible for the SendSignal operation has signature parameters with different run-time values that differientate them.

But this is a bit beyond my expertiese.  I still see this as an EA interface & repository design issue and not an interpretation of the UML.  The UML specifications do not address how a UML tool is to present information in a browser nor how it is to appear in a respoitory.  UML Specs only address the diagrams themselves; not the tool.  

On the other hand, I do think the browser information could be organized in a way more friendly to modelers.    But that is another issue.  

It is time for some Sparxians to get involved in this I think.  I'm curious as to how they might spin this issue.