Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Open Issues

  • Acronym: MOF
  • Issues Count: 8
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

merging the UML package does not merge the elements of UML

  • Key: MOF26-41
  • Status: open   Implementation work Blocked
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    MOF merges the UML package into its Reflection package. The UML contains many packages, such as CommonStructure. The package merge defines that such packages are deep copied into the resulting package. All the packages of the UML are also imported into the UML package. Package merge just copies these import relationships. It doesn't merge the imported elements: UML 2.5: Imported elements are not merged (unless there is also a PackageMerge to the Package owning the imported element).

    In effect, it means that MOF contains two unrelated element definitions: CommonStructure::Element and Reflection::Element. In fact all MOF elements are not merged with their UML counterparts.

    In UML 2.4 all the packages were merged into the UML package. Therefore, all elements were directly contained in this package. Therefore, it was sufficient to merge it.

    A possible solution: Create in MOF a package structure mirroring the UML packages.

  • Reported: MOF 2.5.1 — Fri, 7 Oct 2022 12:10 GMT
  • Updated: Thu, 27 Oct 2022 16:53 GMT

CMOF constraint OCL for ownedEnd is too restrictive

  • Key: MOF26-40
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The OCL is as follows. The restriction that ownedEnd->size() < 2 is not justified by the text of the constraint nor the specification, which refer only to memberEnds and size being limited to 2.
    In fact associations which own both their ends are a frequently used and useful (e.g. to link 2 independnetly developed (meta)models.
    The constraint should be ownedEnd->size() <= 2.

    >>>>>>>>>>>>>>
    – 14.3 [1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e., n-ary Associations are not supported);
    – unlike EMOF, CMOF associations can have navigable association-owned ends.
    – see also: https://sites.google.com/site/metamodelingantipatterns/catalog/mof/association-does-not-have-two-member-ends

    context Association
    inv CMOF_14_3_1: memberEnd->size() = 2 and ownedEnd->size() < 2

    <<<<<<<<<<<<<<<

  • Reported: MOF 2.5 — Tue, 3 May 2022 15:29 GMT
  • Updated: Tue, 3 May 2022 16:56 GMT

Wrong import of the MOF::Common package by the MOF::Reflection package: it's actually the opposite.

  • Key: MOF26-39
  • Status: open  
  • Source: None (independent IT engineer) ( Vincent Guyon)
  • Summary:

    No import of the MOF::Common package is required by the MOF::Reflection package.
    It's actually the opposite because the MOF::Common::ReflectiveCollection class inherits from the MOF::Reflective::Object (cf. Figure 10.2 on page 19).
    The problem is also present in the MOF/20131001/MOF.xmi (ptc/14-08-10) document.

    Another problem in the document: the 10.4 sub-chapter describing the MOF::Common package should not be a sub-chapter of the MOF::Identifiers main chapter (chapter 10), but in a specific main chapter for itself (chapter 11).

  • Reported: MOF 2.5.1 — Sun, 17 Apr 2022 11:40 GMT
  • Updated: Thu, 21 Apr 2022 16:11 GMT

AnnexB: Links to Constraint OCL Files Crossed


Typographical error

  • Key: MOF26-37
  • Status: open  
  • Source: Private individual ( Daniel Flaum)
  • Summary:

    The word 'metamodel' is misspelled as 'meatmodel' in the lower-most paragraph of page 1. The sentence which contains it is:

    "The lightweight subset representing the MOF meatmodel is specified by specifying constraints against the UML metamodel."

  • Reported: MOF 2.5.1 — Tue, 1 Oct 2019 19:11 GMT
  • Updated: Tue, 8 Oct 2019 17:44 GMT

org.omg.emof.oppositeRoleName

  • Key: MOF26-35
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The oppositeRoleName tag was introduced to support inverse navigation by OCL expressions since an OCL navigation needs to know the name to be navigated. An OCL navigation also needs to know whether the far end is a collection or not, and, if it is a collection, whether it is ordered and/or has unique values.The vast majority of opposite end characteristics can be reconstructed by assuming [0..1] !ordered, unique. However for the UML 2.5 model, this erroneously characterizes one ordered collection as not-ordered, about 10 lower bounds as 0 rather than 1, and about 100 upper bounds as 1 rather than 2 or *.

    If EMOF is to be useable by OCL and related tools, additional
    org.omg.emof.oppositeLower
    org.omg.emof.oppositeUpper
    org.omg.emof.oppositeOrdered
    org.omg.emof.oppositeUnique

    tags are need to avoid corruption of metamodel relationships.

    (The discussion on Issue 12800 that introduced oppositeRoleName suggested that the above might be necessary. Experience has shown that they are necessary. For instance for QVTr, a QVTc middle metamodel is synthesized with unidirectional navigation to the user metamodels. These unidirectional relationships are navigated in reverse as part of the trace and must have correct multiplicities.)

  • Reported: MOF 2.5 — Tue, 17 May 2016 14:18 GMT
  • Updated: Sat, 28 Jan 2017 10:13 GMT

The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier

  • Key: MOF26-36
  • Status: open  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier. The sentence currently reads:

    The OCL constraints limiting this metamodel to the MOF 2 - relevant subsets are defined in Clause for EMOF and Clause for CMOF. A reference to files with the OCL source code is provided in Annex.

    There should be a number after "Clause" both times it appears ("12" and "14", perhaps?) and a letter at the end following Annex ("B"?).

  • Reported: MOF 2.5 — Fri, 5 Aug 2016 21:11 GMT
  • Updated: Fri, 5 Aug 2016 21:16 GMT

Conflicting statements about tag multiplicity

  • Key: MOF26-34
  • Status: open   Implementation work Blocked
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    The model in Figure 11.1 ("The Extension package") does not specify a multiplicity for the tag property of MOF::Reflection::Element

    That is in conflict with one sentence in Section 11.1
    "The MOF Extension capability provides a simple mechanism to associate a collection of name-value pairs with model elements in order to address this need."

    and in Section 11.2
    "A model element can be associated with many Tags"

    Just as a sidenote, the two sections have two other issues:
    1) 11.2 is stating that "A model element cannot have more than one tag with the same name." but there is no OCL constraint to formalize that
    2) The property owner:Element [0..1] mentioned in 11.2 is not mentioned on Figure 11.1

  • Reported: MOF 2.5 — Sat, 16 Apr 2016 18:08 GMT
  • Updated: Wed, 27 Apr 2016 14:17 GMT