SBVR15 — Annex H recommends faulty UML constructs

Annex H provides detailed guidance on the representation of SBVR vocabulary concepts in UML diagrams. Much of that guidance produces invalid UML constructs per UML 2.4.

H.1 "If there are additional terms for the concept they can be added within the rectangle, labeled as such – e.g., “also: is-category-of
fact type” as depicted in Figure H.1." There is no UML syntax for this.

H.2 "Alternatively, an individual concept can be depicted as an instance of its related general concept (noun concept), as in Figure H.3." The diagram uses an unidentified Dependency, which has no meaning. It should be formally stereotyped.

H.3.1 shows three representations of the fact type 'semantic community shares understanding of concept'. The third is invalid – an association can have only one name. Also the name of the association is 'shares understanding of'; it does not include the placeholder terms.

H.3.1 Figure H.4 shows associations that are navigable in both directions, inducing unnamed UML properties on 'semantic community' and 'concept' that are not intended. (This is a vestige of UML v1 ambiguity.) It should show no navigable ends, using UML 2.4 syntax.

H.3.4 Figure H.9 depicts an invalid relationship symbol; an association is required to have 2 or more roles.

H.4.2 Figure H.11 shows a stereotype <<is role of>> on a Generalization. I'm not sure this is valid UML, but in any case such a stereotype would have to be defined in a formal Profile. (Semantically, some "roles" are object types that specialize more general concepts, others are association ends (verb concept roles), and others are things in their own right that have the property 'role has occupant'.)

H.4.3 suggests that there is no consistent mapping for association names. In any case, the UML model of a 'fact type role' is a named association end, regardless of ownership.

H.6.1 Figure H.14. It is not clear what UML element has the name "Results by Payment type", and the text does not say. It may be a GeneralizationSet.

H.6.2 Figure H.16. ":modality" appears to be a TagValue associated with some unnamed and undefined Tag, or it may just be another string that names no model element.

H.8 In, Figure H.17 there is a meaningless dashed line between 'car recovery' and a ternary association (verb concept). It is said to represent 'objectification'. That dashed line should be a Dependency that has a stereotype indicating the nature of that relationship, e.g., <<objectification>>, defined in a Profile.

H.9 says that the default multiplicity on association ends is 0..*. According to the UML metamodel v2.4, the default multiplicity on a UML association end is 1..1, i.e., exactly one. This makes most of the SBVR UML diagrams implicitly erroneous.

So Annex H needs to be rewritten, and if it is to include standard stereotypes and tag values, it needs a standard UML Profile that defines them.

Further, it demonstrates the need for minor repairs to the UML diagrams throughout SBVR, to make them match the MOF model described in Clause 13.

Most or maybe all points are fixed by resolution of SBVR 15-08 - Review in SBVR v1.6

(see attached Word document)