UAF 1.0 FTF Avatar
  1. OMG Issue

UAF — Taxonomy as stereotypes rather than a class library

  • Key: UAF-12
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    This issue is related to multiple UAF classes and stereotypes but will be illustrated with “Organization” and “ActualOrganization”.

    UAF contains a taxonomic structure defining useful concepts such as person and organization. These are then represented in UML & SysML and the UAF Profile. Other concepts (e.g. CommunicationsLinkProperties) are represented in a library of concepts. Our recommendation is to use the library of concepts approach more consistently and to have a much smaller profile.

    There are multiple ways concepts like “Person” or “Organization” can be represented in UML/SysML: as classes, instances or stereotypes. UAF has chosen stereotypes.
    The most common way to use UML would be to define a class (Or sysML Block) “Organization”. Instances of that class would be instance specifications such as “International Maritime Organization:Organizaiton”. Particular kinds of organizations would subclass “Organization”, for example “Corporation” may subclass “Organization”. Thus concepts like people and organizations are contained in UML models as classes. Such models may be standardized, reused and extended. This part of UML is well understood and quite functional. For an instance model, such a type is easily used as in “Object Management Group:Organzation”.

    UAF has chosen to make each such concept into a pair of stereotypes e.g. <<Organization>> and <<Actual Organization>>. This makes “Organization” and even “Actual Organization” essentially metatypes instead of Supertypes and instances as one would expect in a UML class model. Another interpretation of a stereotype is as a “archetype” which is essentially a distinguished supertype – everything marked with such a archetype is a subtype of the archetype. However UAF stereotypes seem to represent metatypes, not Supertypes or archetypes.

    The representation of the UAF taxonomy as stereotypes rather than a class model of Supertypes does not seem to have any clear advantage in terms of defining the concepts. Potential reasons would be: 1) To make the UAF concept appear in the class box, eg, "<<Organization>> Civil Defense Organization". Another may be to allow tools to apply special rules to these types. Both of these effects could be achieved with tooling enhancements referencing a class model. Disadvantage of using stereotypes are: 1) That it makes the taxonomy harder to extend & more brittle. 2) That it makes the UAF profile much larger 3) It requires special UAF tooling. 4) It ends up replicating some built-in UML concepts. 5) Complexity 6) Increased learning curve.

    Recommendation: The UAF taxonomy should be represented as a normal UML class hierarchy that is part of the UAF standard – a library of concepts. User models may subclass these concepts as needed – this is simple and semantically clear. The “Non Actual” taxonomy may be removed as the classes are types (non actual) and instances of these classes would be “actual”. Having a class hierarchy for UAF concepts would be reusable with no dependence of any other part of UAF or SysML.

    Option: If additional tooling help is required, stereotypes may be defined for distinguished classes in the taxonomy, with the same name. These stereotypes would simply mean that the user defined class is a (direct or indirect) subtype of the UAF defined class. Such stereotypes are sometimes thought of as “Archetypes”. Using this mechanism, there is no reason to define both “Organization” and “ActualOrganization” as UML already has a mechanism to define an instance for any class. Archetype stereotypes would retain more compatibility with Beta UAF.

  • Reported: UAF 1.0b1 — Thu, 23 Feb 2017 23:38 GMT
  • Disposition: Closed; No Change — UAF 1.0
  • Disposition Summary:

    Taxonomy as stereotypes rather than a class library

    Not in the scope of FTF.
    1. We cannot redefine the foundation in the scope of the FTF
    2. The change in foundation would destroy compatibility with previous versions of the standard
    3. Hard for modelers to understand and use

  • Updated: Mon, 16 Oct 2017 15:16 GMT