Skip to content

Support unparsing when behavior annex has resolution errors #2459

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

Closed
philip-alldredge opened this issue Sep 25, 2020 · 7 comments · Fixed by #2510
Closed

Support unparsing when behavior annex has resolution errors #2459

philip-alldredge opened this issue Sep 25, 2020 · 7 comments · Fixed by #2510
Assignees
Milestone

Comments

@philip-alldredge
Copy link
Collaborator

Update OSATE and the behavior annex plugin to support accessing and unparsing of any parsed behavior annex regardless of resolution issues. This is helpful for the graphical editor to allow editing behavior annex subclauses when there are resolution or legality errors.

Parsed annex sublause is null whenever a resolution error occurs.

The parsed annex subclause is set to null if there are any resolution errors. This behavior should be removed by removing the following lines from AnnexParserAgent

if (resolveErrReporter.getNumErrors() != 0) {
	setParsedAnnexSection.accept(null);
}

Unparsing fails in some cases

In some cases the behavior annex unparser fails and produces unexpected results. Given the following model:

package ba_unparse
public

	system top
	annex behavior_specification {**
		states
			s3 : state;
		transitions
            t1 : s1 -[]-> s2 {
              o1 := tmp + 1
            };
        **};
end top;
	
end ba_unparse;

Adding a new state and unparsing with the graphical editor and unparsing produces:

public

	system top
	annex behavior_specification {**
          states
            s3 : state;
            top_new_state : initial state;
          transitions
        **};
end top;
	
end ba_unparse;

The following message appears in the console of the development environment: aadlba unparsing failed for : DeclarativeBehaviorTransitionImpl

There may be other unparsing cases that are problematic but these are the ones we have experienced so far.
@RyanMcilnay please add comments with any other cases where unparsing fails. You'll need to make the change to AnnexParserAgent first.

@philip-alldredge
Copy link
Collaborator Author

@Etienne13 this is the issue we've been discussing.

@Etienne13
Copy link
Contributor

I am almost ready to provide a fix for this issue; it does not cover all the possible cases, but provides a first coverage of the unparsing for unresolved BA subclauses.

However, I would like to ensure that changing the AnnexParserAgent is sound. In particular, with respect to issue #1863 .

Indeed, if we do not set the parsed annex section to null in case of resolution errors, the BA model gets validated (either by Xtext or by EMF, not sure about this) and the error report is impossible to understand - see #1863 .

@lwrage : do you see a way to prevent this EMF-like validation when resolution errors have been set? Right now it is done by setting the "parsed annex section" field to null but this prevents from unparsing...

@lwrage
Copy link
Contributor

lwrage commented Sep 29, 2020

I'm not sure. The validation is done by EMF because it (in #1863) refers to something inside the BA. I don't know how that is triggered. The error message "The required feature ... must be set" comes from the EObjectValidator line 726, I think.

@RyanMcilnay
Copy link
Contributor

@Etienne13 What is the status on this issue and are we able to help at all to get this resolved?

@Etienne13
Copy link
Contributor

Etienne13 commented Oct 19, 2020

For the BA unparser, most of the code is ready to be merged to OSATE.

I needed to talk about the issue with @dblouin, to find a way to deactivate the EObjectValidator instead of setting the "parsed annex section" field to null. We just talked about it and Dominique will suggest a way to achieve this.

The objective is to replace the following code (from AnnexParserAgent)

if (resolveErrReporter.getNumErrors() != 0) {
	setParsedAnnexSection.accept(null);
}

by a deactivation of the EMF validator. This mechanism should be provided by OSATE to deactivate EMF validation of annexes.

@Etienne13
Copy link
Contributor

Thanks @dblouin for your help on this issue; @philip-alldredge, @RyanMcilnay and @lwrage a fix has been pushed into branch 2459_unparsing_unresolved_behavior_annexes. I also created a pull request.

Could you try and let us know if it solves your problem or if we need to work more on this before merging into master?

@RyanMcilnay
Copy link
Contributor

@Etienne13 These changes seem to fix our issue. Thank you!

@lwrage lwrage added this to the 2.9.1 milestone Jan 19, 2021
lwrage pushed a commit that referenced this issue Feb 16, 2022
lwrage pushed a commit that referenced this issue Feb 16, 2022
…n case of resolution errors"

This reverts commit 27c0af2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants