search

Geonovum / uml2json

Best Practise for OGC - UML to JSON Encoding Rules
https://geonovum.github.io/uml2json/document.html
0 stars 1 forks source link

Figure 11 and stereotype «type» in table 2 #37

Closed heidivanparys closed 4 months ago

heidivanparys commented 1 year ago

This issue is related to #30.

Using UML classes stereotyped «type» is something that was done in ISO 19103 when it was based on UML 1. In UML 2, the classifier Interface is used for this (having as notation a solid-outline rectangle with the keyword «interface»; interface ≠ class). In order to avoid confusion, wouldn't it be better to stick to UML 2, and only use interface? If needed, the text in table 2 regarding «type» could be added as a note to table 2.

CharacterString, Real, etc. are modelled as interfaces in ISO 19103:2015, see e.g. http://iso.sparxcloud.com?m=1&o=0A614EA9-13B7-4ebe-85ED-AA187D27CBD1. So Figure 11 should be modified to use interfaces, and the specialising classifiers should also be interfaces.

Additional note on figure 11: Boolean and MyBoolean could be left out completely, do those add anything? And then the fact that Boolean in 19103:2015 is modelled as an enumeration and not an interface can be hidden…

image

https://www.uml-diagrams.org/classifier.html:

image

jechterhoff commented 4 months ago

@heidivanparys: The table with stereotypes has been updated, as you suggested, and a note has been added to explain the use of stereotype «type». Figure 11 has been updated as well, to remove the boolean case. What I have not done is change the stereotypes and model elements there (and to a certain extent in other UML diagrams), because that would be a significant amount of work that I'd like to avoid at this point. After all, there is now clarification that «type» and «interface» can both be used, the former especially in cases of still-prevalent "old-school" application schemas. See commit https://github.com/Geonovum/uml2json/commit/46877a0958d43e9263ad6978cb9ed6acdf1be332 for details. Is that sufficient? If so, please close this issue.

heidivanparys commented 4 months ago

I had a quick look. The commit introduces a few errors (an interface is not a class). I can make a pull request to identify those changes. I'm afraid I have no time this week, but I can do that in the course of next week, if that's ok?

jechterhoff commented 4 months ago

You are probably referring to the cases where I added stereotype «Interface», and the original text referred to class (like the terminology on object types, and the requirement for association classes).

Thanks for offering to create a PR. Looking forward to it.

PalmJanssen commented 4 months ago

What about the codeList? I expect it to be of the MetaClass DataType and not Class.

heidivanparys commented 4 months ago

You are probably referring to the cases where I added stereotype «Interface», and the original text referred to class (like the terminology on object types, and the requirement for association classes).

@jechterhoff Yes indeed. I can see that those texts have been updated already in the meantime, so I actually have no comments any more regarding interfaces, so for me, this issue can be closed.

What about the codeList? I expect it to be of the MetaClass DataType and not Class.

@PalmJanssen This was defined in an ambiguous way in ISO 19103:2015, which resulted in implementations taking different approaches. Therefore, in the UML profile of the upcoming ISO 19103:2024, CodeList actually extends Class, DataType and Enumeration. The modeller can then choose what metaclass to extend for the codeList construct, if still using this deprecated stereotype. A similar comment applies to Union.

jechterhoff commented 4 months ago

@jechterhoff Yes indeed. I can see that those texts have been updated already in the meantime, so I actually have no comments any more regarding interfaces, so for me, this issue can be closed.

Thanks. Closing this issue now.