Support unparsing when behavior annex has resolution errors

[philip-alldredge]

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]

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

[Etienne13]

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]

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]

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

[Etienne13]

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]

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]

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