New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ErrorModelScopeProvider using wrong scope for element references #114

Closed
rinsley opened this Issue Sep 21, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@rinsley

rinsley commented Sep 21, 2016

I am encountering problems serializing a programmatically created model that I believe are due to errors in ErrorModelScopeProvider.xtend.

In ErrorModelScopeProvider.xtend on lines 347 and 348, it establishes the scope to use when serializing a reference to a subcomponent state, for example, a subcomponent state in a composite error behavior state.

It declares the scope for this is the subcomponents of the referenced subcomponent's component classifier. This appears to be wrong. The scope should be the subcomponents of the component implementation that contains the composite error behavior.

Similarly, in ErrorModelScopeProvider on line 237, it establishes the scope to use when serializing a reference in an error behavior state machine transition.

It declares the scope as all of the events in the error behavior state machine. This is incomplete, This scope should also include the error types used by the error behavior state machine.

@joeseibel

This comment has been minimized.

Show comment
Hide comment
@joeseibel

joeseibel Oct 19, 2016

Contributor

Can you give an example where an error type should be in the scope for EMV2PathElement's namedElement reference?

Contributor

joeseibel commented Oct 19, 2016

Can you give an example where an error type should be in the scope for EMV2PathElement's namedElement reference?

@joeseibel joeseibel reopened this Oct 19, 2016

@rinsley

This comment has been minimized.

Show comment
Hide comment
@rinsley

rinsley Oct 19, 2016

package FailExample
public
annex EMV2 {**
error behavior FailStop2
use types ErrorLibrary;
events
Failure : error event {ServiceError};
states
Operational : initial state ;
FailStop : state ;
transitions
FailureTransition : Operational -[ ServiceError ]-> FailStop ;
end behavior ;
**};
end FailExample;

Here, the transition condition uses an error type. I believe this is valid, it doesn't give any errors in the OSATE editor.

rinsley commented Oct 19, 2016

package FailExample
public
annex EMV2 {**
error behavior FailStop2
use types ErrorLibrary;
events
Failure : error event {ServiceError};
states
Operational : initial state ;
FailStop : state ;
transitions
FailureTransition : Operational -[ ServiceError ]-> FailStop ;
end behavior ;
**};
end FailExample;

Here, the transition condition uses an error type. I believe this is valid, it doesn't give any errors in the OSATE editor.

@lwrage

This comment has been minimized.

Show comment
Hide comment
@lwrage

lwrage Oct 20, 2016

Contributor

The transition in the model above is not valid. The standard allows error events and propagation points as condition triggers but not error types. The name resolver has a bug here which will be fixed with #103, so I'm closing this issue.

Contributor

lwrage commented Oct 20, 2016

The transition in the model above is not valid. The standard allows error events and propagation points as condition triggers but not error types. The name resolver has a bug here which will be fixed with #103, so I'm closing this issue.

@rinsley

This comment has been minimized.

Show comment
Hide comment
@rinsley

rinsley Oct 20, 2016

Sounds good to me.

rinsley commented Oct 20, 2016

Sounds good to me.

@lwrage lwrage closed this Oct 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment