Interfaces vs. abstract classes (Deriving from Any)

[ilkkarinne]

@cportele (or some other 19103 expert): The target for the associations metadata and result in the draft UML model is currently AnyType::Any interface linked from the ISO 19103 Edition 1 model. If we want to provide specializations of Any for adding inverse associations towards the AbstractObservationBase (as discussed in issue #44) should we define new interfaces for the AnyObservationMetadata and AnyObservationResult or (abstract) classes?

In the implementation level we see the in most cases there will be existing metadata and various result entities in most systems, and we don't want to formally force them into specialising our AnyObservationMetadata and AnyObservationResult classes, but instead define a pre-defined pattern for providing bi-directional navigation when considered useful.

[cportele]

@ilkkarinne - I don't really see a way how to achieve all of this in UML with the existing harmonized model (as discussed in #44).

[ilkkarinne]

We had another discussion on using interfaces in the 29 Apr SWG. @cportele: Was it you that argued against using interfaces in the O&M UML model in one of the Github discussions in order to not mix different (meta) modelling levels?

Is there specific guidance on using (or not using) the stereotype interface in the ISO/TC 211 UML models? If it can be used in the model like we have for the O&M v3 what is the difference of describing an entity as interface or an abstract class (assuming that the abstract class would have no operations defined)?

Would it be OK to define the aspect of having an 0..* association to an AbstractObservationBase as an interface, and then make all the classes designed to contain this aspect realize this interface in the model?

[ilkkarinne]

The latest UML draft has now been revised following the interface pattern described above, see https://github.com/opengeospatial/om-swg/blob/master/iso_19156_issues/ea/2020-05-07_Observation.png

All the associations pointing towards sub-class instances of AbstractObservation are now captures under the interface ObservationRelated, which is then realized by SimpleFeatureOfInterest, SimpleProcedure, SimpleObservableProperty, SimpleObserver, SimplePlatform and the AbstractObservation itself (observation context). The ObservationRelated has a single directed association to AbstractObservation with role name relatedObservation and qualifiers sourceRole and targetRole.

@cportele, @jetgeo and others: do you see issues with this model regarding to the harmonized model or TC 211 UML modelling best practice?

[jetgeo]

I have some concerns from an ISO/TC 211 HMMG point of view. First - I can't seem to find the updated model in the HM. Are you doing the modelling outside of the HM now? If so, we should have an updated version in the HM before the virtual meetings in June. We can discuss this part directly on email, no need for everyone to be included.

Second - according to requirement 4 in ISO 19103, each model shall have documented a clear description of its level of abstraction (loa) (https://github.com/ISO-TC211/UML-Best-Practices/wiki/Level-of-abstraction). The model you have suggested is mixing levels of abstraction: interface from the abstract level and feature types from the application schema level. This approach goes against the 19103 requirement and our best practices. A feature type can implement an interface, but an interface cannot have an association to a feature type. You need to separate the parts of the model based on the loa.

[ilkkarinne]

@jetgeo: on the levels of abstraction: If I understand your comment correctly we would need to split the O&M model in two parts, an abstract schema and an application schema, in order to fulfil the 19103 requirements.

Would it be sufficient in the abstract schema to specify an Observation interface and an ObservationRelated interface associated with the Observation interface? Then in the application schema the AbstractObservation (feature type) would implement the Observation interface and the various other classes willing to link back to one or more Observations would implement the ObservationRelated interface, as in the current UML draft?

I guess we would in this case have to rename either the current Observation feature type or the new proposed Observation interface to avoid a naming conflict.

[jetgeo]

@ilkkarinne: Yes, you should split the model according to the levels of abstraction. The application schema level concepts should be defined in a specific class stereotyped "Application schema". Without looking at the model, I believe your suggested solution should be sufficient. In order to avoid name conflicts, you may add an "I" as prefix for the interface classes. That's the way it has been done in e.g. ISO 19148.

[ilkkarinne]

Ok, I will have to think about which things in the UML model would go to which schema in that case, perhaps there is no need for most of the abstract feature type classes in the application schema, if they can be defined as interfaces in the abstract schema.

[ilkkarinne]

I have now split the draft O&M 3.0 into three UML packages:

• Abstract Observation schema (abstract schema level)
• Observation Core (application schema level), and
• Basic Observations (application schema level)

The Abstract Observation schema contains the essence or the O&M 3.0 concepts as interfaces, the core defines the core O&M feature types and the Basic Observations provides simple feature types ready to use without the need to extend the abstract core classes.

Let's have a look at this in the SWG meeting today.

[KathiSchleidt]

Open question - is there any reason to make Platform and Observer FeatureTypes?

[ilkkarinne]

I've now updated the models listed above based on the 27th May SWG discussion. Please check if the asbstract schema + application schema levels now look OK to you eyes @cportele and @jetgeo:

• Abstract Observation schema (abstract schema level)
• Observation Core (application schema level), and
• Basic Observations (application schema level)

The complete EAP file is available at https://github.com/opengeospatial/om-swg/raw/master/iso_19156_issues/ea/isotc211_hm_om_revision.eap if you're interested in looking at that.

@KathiSchleidt : I removed the AbstractPlatform and the AbstractObserver feature types from the core model as requested.

[ilkkarinne]

The current abstract schema - core application schema dependency relies on the semantics that the 19109 AnyFeature at least implicitly realizes the 19103 Any interface: the "feature-of-interest" associations of the Abstract Observation schema ObservationCharacteristics interface with the ultimateObjectOfInterest and proximateObjectOfInterest role names pointing to 19103 Any are explicitly redefined as the Observation core application schema AbstractObservation class associations with role names ultimateFeatureOfInterest and proximateFeatureOfInterest pointing to 19109 AnyFeature. This would only be constraining if we can say that AnyFeature realizes Any.

Not sure if it makes things unnecessarily complicated to rename the associations like this while redefining them to point to AnyFeature instead on Any. We just did not want to use the "feature" word in the abstract Observation schema, but wanted to keep the familiar "FoI" term for the (GML'ish) application schema.

[cportele]

@ilkkarinne - I had a look at the UML diagrams (I used the latest versions).

In general, the abstraction levels look consistent to me. A few comments/questions though:

• The association class Deployment between Observer and Platform is a class and on a different level of abstraction. However, since it is ok for ISO 19103 to allow attributes and associations in interfaces, I guess that is consistent with the ISO 19103 requirements.
• The statement that ultimateFeatureOfInterest is "redefining" ultimateObjectOfInterest is technically not correct im my understanding as attributes and associations of the interface are not "seen" by the realizing class. Perhaps rephrase to "ultimateFeatureOfInterest implements ultimateObjectOfInterest"?
• In Observation Core the realized classes do not include attributes or all associations of the interfaces, at least in the diagrams. This is just temporary/for better readability?

PS: ObservationRelated is not really clear to me as is the combined use of targetRole and sourceRole in the qualifiers, but that is a separate topic.

[ilkkarinne]

Thanks for the review @cportele. By saying that "attributes and associations of the interface are not 'seen' by the realizing class" do you mean that interface realization does not imply inheriting the interface attributes and associations in UML? If this is the case, what does the realization of an abstract schema interface imply for an application schema FeatureType class?

[cportele]

@ilkkarinne - It is the operations that are "inherited" in a realization.

ISO 19103 says in 6.8.4 (Realizations):

... When used between classifiers, a realization can be thought of as inheritance of behaviour without inheritance of structure as described above. Consequently it is a convenient mechanism for describing shifts in abstraction levels where a concrete element realizes a more abstract element.

[ilkkarinne]

@cportele: Ok, thanks. We'll have to reconsider which attributes and associations to keep at the abstract schema level then, as all attributes and associations also need to be provided for the application schema classifiers. Sigh.

[KathiSchleidt]

@ilkkarinne has this been clarified?