Aadl2JavaValidator doesn't check CLASSIFIER_MATCH correctly

[AaronGreenhouse]

Aadl2JavaValidator doesn't check Classifier_Match sematnics correctly in the method testClassifierMatchRule(). According to the standard:

If the destination classifier is a component type, then any implementation of the source matches.

But the method also allows the src to be a type and the dest to the an implementation of the type. This is well known to be unsafe.

Also, the method currently generates warnings when one classifier is a type and the other is an implementation and the implementation is not an implementation of that type. This should be an error.

[AaronGreenhouse]

Check that bidirectional connections are checked correctly.

Add unit tests

[AaronGreenhouse]

Errors vs warnings (per @lwrage):

• if one end has a classifier and the other has none then it is a warning

that's fine, the model may be incomplete.

• If the classifiers are completely incompatible then it is an error

yes, should be an error

• one is a type and the other is an implementation, and the implementation is not an implementation of that type then it is a warning

that should be an error, instead. Please fix.

[lwrage]

@AaronGreenhouse This does the wrong thing for access connections. There it's not the connection direction but provides/requires that determines "source" and "destination" for the validation. see #2362

[AaronGreenhouse]

Well, it's a bit more complicated than that. The type can become more general towards the ultimate requires. So when checking a connection instance, one end is a requires and the other end is either a provides or a component instance. So the original rule

If the destination classifier is a component type, then any implementation of the source matches.

should be interpreted in this case as

If the classifier on the requires features is a component type, then any implementation of the provides or component matches.

Easy enough.

Things get trickier when checking the declarative model. We must also consider which way is traveling toward the ultimate requires feature. The classifier type information flows in the following directions:

• sub -> sub.r (Subcomponent to requires feature of a sibling subcomponent)
• sub -> p (Subcomponent to a provides feature of the containing component)
• sub.p1 -> p2 (provides feature of a subcomponent to a provides feature of the containing component)
• sub.p -> sub.r (provides feature of a subcomponent to a requires features of a sibling subcomponent)
• r -> sub.r (requires feature of a component to a requires feature of a subcomponent)

These are distinct from the declared directions of the connections, which indicate whether the shared component is written to or read from. So both endpoints of a declarative connection need to be looked at to determine which one should be consider the "source" and which one should be considered the "destination" for the type checking.

[AaronGreenhouse]

Declarative checks are in and have unit tests.

[AaronGreenhouse]

Connections in the instance model aren't so straightforward either because we allow instantiation of incomplete models. Thus, we still have to go through some gymnastics to figure out which end of the connection belongs to the provider of shared access, and which end is the requirer.

The best case is when one end of the connection is a ComponentInstance: that end is the provider.

When both ends are FeatureInstances then we have to do the same general tests that we have above for declarative models. Only it's much more inconvenient to figure out if a FeatureInstance is a requires or provides.