Bidirectional Associations

[KathiSchleidt]

In many cases, it could be advantageous to define the associations between classes as bidirectional (cardinality 0..x, so can be left out as required). Is this OK with ISO principles, or is there some agreement on keeping associations directed?

[cportele]

Neither ISO 19103 nor the GFM add any constraints with respect to the navigability of association roles in UML. The GFM requires that at least one of the association roles has a name and is navigable.

[ilkkarinne]

All of the UML associations have now been updated to be navigable at least in one direction. We need to review the single-directional ones to see which ones we want to make bidirectional.

[ilkkarinne]

We had a discussion on expressing navigability in UML and particularly with EA in our last SWG meeting. It seems that at least in EA the association end is automatically turned into an arrow is the navigability is enabled for that direction, and there is no visible difference between a non-navigable and unspecified navigability. Thus to make an association navigable in the other direction and with an unspecified navigability to the other direction, EA creates a single-direction arrow line, as it does in cases where the other side is explicitly non-navigable. A single-direction arrow was interpreted by the SWG meeting participants as non-navigable in the other direction.

When an association is set to be navigable in both directions, EA creates a two-sided arrow line. However, a common practice in UML diagrams seems to be that a line with no arrows also is considered as an association navigable to both directions, at least when role names and cardinalities are given at both ends.

@cportele: what is the ISO/TC 211 practice in expressing in UML class diagrams

• associations with navigable in one direction and with unspecified navigability in the other, and
• associations navigable in both directions?

[cportele]

@ilkkarinne - See the TC 211 wiki: https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-roles-and-navigability

[ilkkarinne]

The SWG members also wanted to make it possible for O&M implementations to have associations with role names ultimateFeatureOfInterest and proximateFeatureOfInterest from AbstractObservationBase to (ISO 19109) AnyFeature navigable also in the inverse direction (from FoI to Observation). Similarly the SWG members would like to enable O&M implementations to have associations with role names result and metadata from AbstractObservationBase to (ISO 19103) Any navigable also in the inverse direction (from metadata or result to Observation).

We did not want to make it mandatory for the implementations to provide the inverse navigabilities, but provide harmonisation by a standard role name between implementations which choose to provide this inverse direction navigation.

After some thought I'm hesitant in adding the inverse navigability (and role names) for these associations, as AnyFeature and Any are defined outside the O&M model, and (naturally) have no such associations pointing towards Observation.

I see three somehow feasible options to proceed:

1. Make these associations navigable towards AnyFeature and Any, non-navigable towards AbstractObservationBase and leave out the inverse role names and cardinalities,
2. Make these associations navigable towards AnyFeature and Any, with unspecified navigability towards AbstractObservationBase and provide the inverse role names and cardinalities (the association line would appear identical to the option 1), or
3. Create O&M specific classes (or abstract classes) for FeatureOfInterest, Metadata and Result and make the associations between AbstractObservationBase and these classes navigable in both directions and provide role names and cardinalities for both ends.

@cportele: any suggestion on how we should proceed?

[cportele]

@ilkkarinne - I agree. Since AnyFeature and Any are not owned by O&M, changing the specification of these classifiers would require an update to ISO 19103 and ISO 19109. But if this would be done, it would create a circular dependency (19103 and 19109 would have to import 19156, too), which is invalid in the OGC specification model.

Option 2 sounds a bit like a hack to me. If the decision would got for option 3, the classifiers could also be subtypes of Any / AnyFeature. Without much thinking about this that seems to be the cleanest way forward.

Or maybe discuss the topic with the HMMG?

[ilkkarinne]

I agree that the option 3 would be a clean one, but I'm worried that by defining dedicated classes for FoIs, metadata and result does not convey the intention that the implementations are free to use any feature (FoI) or any entity (metadata & result) as target of these associations. Subclassing AnyFeature and Any (can we subtype an interface?) could help, but still it may not be as clear as I would like.

One additional option that I do have in mind is doing the option 1 and adding recommendations to the specification stating that in cases where inverse navigability from the concrete classes substituted for AnyFeature and Any to the associated Observations is desired, the association role name 'observation' should be used.

[KathiSchleidt]

For the abstract classes, concrete simple classes have been provided that carry the other direction of the association For the Any classes, this will be continued in #52