ST6RI-953 Extract parsing and linking completion concerns to Xtext modules

[adaussy]

This PR moves parsing/linking-specific postProcess() behavior out of the model adapters and into dedicated Xtext parser adapters.

Background

The textual notation grammars in the KerML and SysML specifications have several productions that parse some segment of text into an element that is synthesized into a meta-property, but then also assigned to another property. This second step is done using the { ... } notation in the specification BNF.

For example, in the specification BNF, an owned Specification is parsed this way:

OwnedSpecialization : Specialization =
    GeneralType

GeneralType : Specialization =
      general = [QualifiedName]
    | general = OwnedFeatureChain
      { ownedRelatedElement += general }

That is, and owned Specialization is specified with just a general type (the owner is the specific type). The general type is parsed as either as a named reference or an owned feature chain. In the latter case, the feature chain is also added to the ownedRelatedElements to establish ownership.

Unfortunately, the Xtext grammar language doesn't support doing this sort of thing. In the Xtext grammars, the corresponding production is

OwnedSpecialization returns SysML::Specialization :
	  general = [SysML::Type | QualifiedName]
	| ownedRelatedElement += OwnedFeatureChain
;

That is, an OwnedFeatureChain gets added to ownedRelatedElement (because Xtext requires every element in the parse tree to have an owner), but does not get assigned to general.

In order to make up for Xtext deficiencies such as this, after parsing a model, the implementation does post-processing on each model element. For example, the post-processing for Specialization checks whether general is null. If so, it sets general to the first ownedRelatedFeature. In the end, this achieves the parsing required by the specification production.

Previously, post-processing code was included in a postProcess method on the ElementAdapters for elements that needed post-processing. However, this post-processing is specific for handling the limitations of the Xtext grammar language. Other parsers may not have such limitations, or may have different ones. Since the code in org.omg.sysml.logic (where the adapters now are) is supposed to be parser-independent, the Xtext parser-post-processing code needed to be separated from the other adapter code.

Changes

1. Added omg.org.kerml.xtext.postprocessing package, with KerMLParserPostProcessorFactory to instantiate various statelessParserPostProcessor classes for KerML element post-processing. Updated org.omg.kerml.scoping.KerMLLinker.postProcessAll() to use the new factory, while preserving previous functionality.

2. Added omg.org.sysml.xtext.postprocessing package with SysMLParserPostProcessorFactory, extending KerMLParserPostProcessorFactory and adding additional ParserPostProcessor classes for SysML. Added org.omg.sysml.scoping.SysMLLinker to use the new SysMLParserPostProcessorFactory.

   This keeps parser-specific model completion concerns in the Xtext layer and separates them from the long-lived semantic model adapters.

3. Revised postProcess methods as necessary so they all call super (except for the top-level ElementParserPostProcessor).

[seidewitz]

I made two changes myself.

1. Moved ParserAdapterTest and UsagePostProcessingTest from org.omg.sysml.semantics.tests to org.omg.sysml.interactive.tests. Parser post-processing is syntactic, not semantic. The semantics.tests are only for testing implementation of implied relationships (based on semantic constraints). I also revised UsagePostProcessingTest to use the interactive test parsing framework (it didn't seem worth doing this for ParserAdapterTest.
2. Updated postProcess methods as necessary so they always call super. This has always been the intent, even though it seems quite a few of the post processing methods for various kinds of relationships were missing these calls. Fortunately, it seems that the only post processing that was missed in these cases was the unescaping of declared names (in ElementParserAdapter).

[adaussy]

@seidewitz I have a new version I hope that match all your comment because I'm not sure about what to do with "For other subtypes with multiple inheritance"

[seidewitz]

@seidewitz I have a new version I hope that match all your comment because I'm not sure about what to do with "For other subtypes with multiple inheritance"

Yeah, I wasn't entirely clear here. What I meant was to fill in the post-processors for intermediate superclasses of any existing processing class, so the post-processor inheritance hierarchy for KerML and SysML is a subset of the abstract syntax hierarchy, with no level skipped. I went ahead and pushed a commit with the additional post-processor classes.

Please review my latest update. If you agree with it, we can go ahead and merge this PR. Or, if you see problems, please comment.

[seidewitz]

I also update ParserPostProcessorTest, because I tracked some intermittent build failures to it. It turns out that the logic module setup you were doing in this test class was interacting badly with the Xtext-based SysMLInteractiveTest framework. This somehow caused problems with the global-scope name resolution. In any case, you don't need to initialize the logic module for this test, because you are not actually using any of the logic capabilities (derived properties, operations and semantic transformation). I removed the logic module set up, and now it builds without any problem.

[adaussy]

@seidewitz I have a new version I hope that match all your comment because I'm not sure about what to do with "For other subtypes with multiple inheritance"

Yeah, I wasn't entirely clear here. What I meant was to fill in the post-processors for intermediate superclasses of any existing processing class, so the post-processor inheritance hierarchy for KerML and SysML is a subset of the abstract syntax hierarchy, with no level skipped. I went ahead and pushed a commit with the additional post-processor classes.

Please review my latest update. If you agree with it, we can go ahead and merge this PR. Or, if you see problems, please comment.

OK this is what I tough but I was not sure if you expect me to do it with this PR or later. Thanks you for making it happen.

I reviewed it quickly and it seems ok. You can merge this PR. (I'm not sure if I'm allowed to merge it myself)

When its done I will rebase my change for ST6RI-950.

Thanks for your review.