Issue 5948: Navigating metalevels/instance relationships
Issue 5996: MOF 2 Issue: Reflexion and Links
Issue 6390: MOF 2.0 Core 03-04-07, Chapter 5. Identifiers
Issue 6408: MOF should include Profile package
Issue 6494: ad-03-04-07/Non-orthogonal additions to UML Core
Issue 6694: diagrams mostly use unspecified «combine»
Issue 6695: chapter 10 rewrite
Issue 6903: Associations should not be required to be unique
Issue 6905: No container for tags in tag model
Issue 6906: ReflectiveSequence is not sufficient, need nulls within a list
Issue 6907: ReflectiveSequence is not sufficient - add iterator, remove addAll
Issue 6908: Remove allowNull and serializable from EMOF DataType
Issue 6910: Correct addAll() input parameter type
Issue 6920: The 'isID' attribute in class MOF::CMOF::Property remains unclear
Issue 7453: semantics of Reflection::Object
Issue 7454: object in a useContainment Extent
Issue 7548: Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF
Issue 7564: MOF Figure 18
Issue 7647: Translation between EMOF and CMOF in MOF 2.0
Issue 7749: Question on M-Levels
Issue 7957: removing section 12.3 EMOF Merged Model ?
Issue 5948: Navigating metalevels/instance relationships (mu2i-ftf)
Click here for this issue's archive.
Source: Queensland University of Technology (Mr. James Steel, james.steel(at)qut.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:
Hi, this question from Mike Lawley @ DSTC (I have CC'd him), > > How does one navigate metalevels in MOF2? "Object" has the operation > "getMetaClass(): Class", but how can I explicitly model (via > a reference/ > association) that MyObj is an instance of MyClass. > > Note, I can see exactly how to do this in CMOF for Links -- > there is an "instance" association between Link and > Association in Fig 8-8. > > Incidentally, is this list the right forum for questions > about the submission, or should it be addressed to a mof-rtf > list or similar?
At the moment getMetaClass() is the only capability. Figure 8-8 is for CMOF Abstract Semantics only so cannot be used by implementations. It is not reasonable to expect the class to be updated when creating elements so there should not be a property owned by Class
The problem
-----------
In the reflexion package of MOF2, the proposal for links assumes that
AssociationEnds are ordered.
There is an implicit mapping between firstObject and secondObject roles and
AssociationEnds is based on this assumption:
FirstObject maps to the first associationEnd
SecondObject maps to the second associationEnd
This leads to the following Operation to create links in the Factory Class:
createLink(association: Association, firstObject : Object, secondObject :
Object): Link
At first glance, this solution provides an easy way to identify the link
members in parameters of link operations. However, the AssociationEnd is
difficult to read. It is closer to relational concepts than to
object/association principles.
One will always have to guess which is the first or second object.
The modeler who has created the association might remember the order. But
the user using the association will probably be lost.
Example:
Country:Class - resident:AssociationEnd (First) - Citizenship:Association
- country:AssociationEnd (Second) - Country:Class
createLink("Citizenhip": Association, "Thomas": Object : "France" :
Object)
Proposal
--------
The idea is to benefit from the semantic carried by AssociationEnds
themselves:
A link defines members. Each member references a participant object
according to a role defined by the AssociationEnd.
Thanks to opposite association of AssociationEnds (aka Property), it is
possible to identify one end from another. This means that if we create
links from an AssociationEnd viewpoint, there is no need to order
AssociationEnd.
The proposal is to order the creation parameters as follow: sourceObject,
oppositeRole, oppositeObject.
Of course, this approach only works for binary associations. But the focus
of AssociationEnd is the first step to take into account nary associations.
This also highlight that what matters most in Association semantic is the
role name of AssociationEnds.
It is usually much more difficult to have a meaningful name for association.
This is why we can often see names such as "has for ..." which do not carry
much information about the association.
All operations on links are redefined as follow:
createLink (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object)
Example:
createLink("Thomas:Object","country:Role","France:Object")
equivalent to:
createLink("France:Object","resident:Role","Thomas:Object")
linkedObjects (sourceObject : Object, oppositeRole : Property) :
Object[0..*]
LinkExists (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object) : Boolean
Proposal Comments
-----------------
A better proposal would not use the opposite role but the role attached to
the object participation to the association.
createLink("resident:Property","Thomas:Object","France:Object")
But experience shows that this is two much unsual for modelers. This would
however be the right path for the introduction of nary associations.
The assumption of ends being ordered is valid since features are ordered. N-ary associations are not supported by either EMOF or CMOF. It is already possible to update the properties at each end using the class interface Disposition: Closed, no change
On page 36: “Identity extends Basic::Property with the ability to designate a property as an identifier for the containing object. Properties: isID: Boolean [0..1] True indicates this property can be used to uniquely identify an instance of the containing Class. Only one Property in a class may have isID==true.” The restriction that only one Property in a class may have isID==true is debilitating. It is common for objects to be identified in the modeled application domain by a unique combination of a set of properties. For example, an object that represents an instance of an n-ary association in the modeled domain will, in general, be identified by a unique combination of n properties, each one of which is an identifier of a participating object in the association. Not being able to carry this natural condition into the MOF requires practitioners to devise a work-around, such as introducing a superfluous surrogate identifier, to be able to externally identify such objects. It is requested that the MOF 2.0 Core specification be revised by the FTF to allow any number of sets of properties to be identifiers. Any client of an object needs to be able to select the identifier set most convenient for them, and different clients need to be able to accurately identify the object, regardless of how other clients may find it. This issue is important to the Business Semantics of Business Rules submissions, which require domain identifiers for objects. Other MOF users will also benefit. Introduction of the Identity package is a potentially powerful and badly needed improvement over MOF 1.x to enable the use of external identifiers for MOF objects, which will greatly facilitate accurate model interchange, reuse, aggregation, and transformation. The present limitation stunts this potential. Please take this modest extra step to assure the full potential of the Identity package can be realized.
It is possible to create a derived property to combine multiple other properties to form the unique id. Disposition: Closed, no change
The Infrastructure library contains a Core model package and a Profile package. The former is reused in MOG, but the latter is not part of MOF. This means that MOF QVT submissions cannot build on the Profiles concept for marking (meta) models and they cannot define mappings for profiled meta models. MDA style mappings from PIM to PSM or between PSMs requires support for mapping between profiled models in many UML modeling tools that implement PSMs as profiles. If MOF QVT cannot deal with mappings to and between profiled models, these tools will require another solution.
Profiled models are just models and the classes in Profiles are just metaclasses to MOF and so exchanged in the normal XMI manner (see chapter 18 of UML2 Superstructure). MOF QVT has managed to complete without any change being required to MOF Core. Disposition: Closed, no change
Issue: The MOF 2 Core specification adds elements to the meta-metamodel that are not part of the UML 2 Core. For example, see the sections entitled "EMOF Extensions to Basic" and "CMOF Extensions to Core::Constructs." The MOF 2 Core's abstract syntax should be a subset of UML. (For detailed explanation of why this is advisable, see ad/03-03-30). Note that this subset principal allows for MOF to specify orthogonal "mix-in" elements, such as packages for reflection and identity. Recommendation: Either add the extra elements to the UML 2 Core or else remove them from MOF.
The extensions were removed prior to MOF finalization. Disposition: Closed, no change
The diagrams mostly use «combine», but what that means is not specified. The defined package merge types are define and extend.
Resolved in FTF Disposition: Closed, no change
The submitters decided to put off to the FTF the chapter 10 rewrite, to correct text that refers to capabilities removed from the final submission. Proposed resolution: This reporter will prepare a proposed rewrite
Resolved in FTF Disposition: Closed, no change
I disagree with [7] (in Reflection Factory Constraints) - this is something we had a lot of discussion about with Steve and Joaquin and it was agreed that Associations should not be required to be unique.
Summary: The tag model is lacking a container for tags. Why not make tags NamedElements (need to check if that’s good enough)?
The proposal in the issue would introduce some incompatibilities, and make it hard to include them in separate models. It would also not allow MEOF packages to contain Tags Instead a Tag should be able to reference its container.
Summary: For interoperability with the XML relational databases, we need to be able to support nulls within a list
ReflectivSequence is adequate for representing values of MOF properties for which it is needed: in MOF ‘null’ is not an explicit value that can be maintained in a property. Disposition: Closed, no change
Summary: Martin has proposed adding an iterator operation Iterator and removing addAll. Iterator would return a ReflectiveIterator that can be used to iterate through all the elements of the collection. If the underlying collection changes while holding an iterator, the behavior of iterator is undefined.
EMOF: - DataType.allowNull should be removed - DataType.serializable should be removed. What are the use cases for it? It seems to me that all the values need to be serializable to allow interoperability
Resolved in FTF, these properties are no longer present. Disposition: Closed, no change
ReflectiveCollection::addAll should take a ReflectiveCollection, not a ReflectiveSequence
The 'isID' attribute in class MOF::CMOF::Property remains unclear for constructed types like e.g. collections. Proposed resolution: Detail specifcation of the 'isID' attribute with respect to other than primitive and class types. Suggestions: (1) identity is established for more complex types if identity 'isID' or "natural" identity (i.e. creation based identity) is given recursively for all referenced instances, or (2) if e.g. a collection has itself identity, then identity is established if the collections are the same
Property isId is only defined on properties of a Class so does not apply to constructed types such as the collection types. Disposition: Closed, no change
According to page 17, the semantics of Reflection::Object require that all instances of MOF model elements must specialize EMOF::Object. My question is, does this specialization have to be explicit or implicit? That is, if I create a blank MOF Class and ask for its superclasses, will they include EMOF::Object? If I send it a "getMetaClass" message, for example, will it understand it, or do I have to explicitly add EMOF::Object to its superclass property?
(Note that Object and Element are now reversed in the MOF2 specification in relation to the issue summary.) The fact that all instances of MOF2 Classes are Elements (and therefore support reflection) is implicit in any MOF2 implementation. It does not have to be explicitly stated in a MOF2 model. However, getMetaClass() and Class::superClass will not include Element as these are tool runtime concerns not covered by the model. The resolution to 13127 provides clarification. Disposition: Closed, no change
Why is that an object in a useContainment Extent cannot have the extent as its container? (This is stated on page 22 of the Final Adopted Spec
This refers to the following text from the FAS which was removed by the FTF: If exclusive()==true, these objects must have container()==null. The reason in general is because Extent does not inherit from namespace. Disposition: Closed, no change
The EMOF model should contain a tag on EMOF:Element of XMI ContentType with value "any". See the discussion and resolution of MOF 2 XMI FTF issue 6345 for background.
I'm confused by something in MOF Figure 18. I see that this is a "semantic domain model," and i know i'm not clear on what that means. But i feel my question makes sense absent a clear understanding of what the MOF specification means by 'semantic domain model.' This diagram is apparently the extension of "the UML 2 Instances model" mentioned at 15.1. I'll assume 'Instances model' means the Infrastructure package, Instances. And, indeed, the drawing there is (mostly) reproduced in Figure 18. My question is about the extensions shown. I'll pick one such extension to make the question concrete. The drawing shows a class, Instance, a subclass of InstanceSpecification. The Infrastructure specification is clear: an instance and an instance specification specifying that instance are not in the same model. My question: Does the term 'instance' have a different meaning in MOF than in the Infrastructure, or are the objects of the class, Instance, not instances, or what?
The meaning of “instance” is the same in MOF2 and InfrastructureLibrary. The subclasses of InstanceSpecification in MOF2 Semantics Domain (Instance, ObjectInstance, ElementInstance, DataValue, ClassInstance, AssociationInstance, etc.) are intended to provide more convenient access to an InstanceSpecification’s classifier and slots for more specific purposes. Disposition: Closed, no change
I am reading the "Meta Object Facility (MOF) 2.0 Core Specification" document ptc/03-10-04. In the section about EMOF, there is the statement "The value of Essential MOF is that it provides a straightforward framework for mapping MOF models to implementations such as JMI and XMI for simple metamodels." From that statement, I inferred that the reason that EMOF exists is largely to define XMI 2.0 and (hypothetically) JMI 2.0. In particular, it seemed from reading the EMOF introduction that the XMI 2.0 and JMI 2.0 specifications would depend only on EMOF (and NOT depend on CMOF). However, when I read the XMI 2.0 spec., it specifically provides mappings for features in CMOF that aren't in EMOF, so implementing/understanding EMOF is not enough to implement/understand XMI 2.0. There is no JMI 2.0 specification yet, but it seems likely that the case would be the same as with XMI 2.0. Therefore, it is not clear to me what the purpose of EMOF is. When is using EMOF more appropriate than using CMOF? Are there any examples of complete EMOF models? In particular, does anybody have the EMOF model defined as an instance of itself, as an XMI document? I could only find the EMOF model defined as an instance of CMOF. And finally, is it possible to represent the (merged) CMOF model as an instance of the EMOF model (useful for bootstrapping)? Finally, is there a well-defined mapping between EMOF and CMOF? That is, how can I convert an instance of the EMOF model to an instance of the CMOF model, and vice versa?
EMOF is considered the bare minimum necessary to capture structural models. It is intended to facilitate model construction and integration through minimum modeling capabilities having proven utility, can be efficiently implemented, and are commonly used in practice. There are many examples of EMOF models, see www.eclipse.org/emf. EMOF is a subset of CMOF, which is produced by adding additional InfrastructureLibrary::Constructs modeling features to EMOF. So any EMOF model is compatible with CMOF. Since CMOF has modeling capabilities that are not included in EMOF, there could be no information preserving mapping from CMOF to EMOF without introducing Tag extensions to EMOF. It is not clear this would be appropriate. If CMOF capabilities are needed, then a CMOF enabled tool should be used to access them. If EMOF capabilities are sufficient, then either an EMOF or CMOF tool could be used. Disposition: Closed, no change
section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF.
Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate.
However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object.
The sentence from 7.2 suggests that I can have the following:
myDog.getClass() == Dog
Dog.getClass() == UML::Class
UML::Class.getClass() == MOF::Class
However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance.
Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance.
Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above.
Any ideas?
MOF::Class and UML::Class are two different classes with different capabilities. The fact that they are both instances of MOF::Class is not relevant. Either MOF or UML could be used to define a class Dog – it is simply a class at the M1 level describing instances of dogs at the M0 level (Fodo, Duke, and Fluffy for example). Whether one uses MOF or UML to define Dog is a matter of what the modeler wants to do with the class. UML doesn’t support reflection. So if UML is used to define Dog, then Dog is an instance of a UML::Class and can’t be reflected. However, a tool could choose to merge MOF::Reflection into a UML compliance level in order to achieve this capability. Disposition: Closed, no change
Issue 6494 resolution calls for removing section 12.3 EMOF Merged Model. Removing this section would require readers to understand and mentally perform a package merge in order to see the complete EMOF model. It would also make it necessary for EMOF implementers to have an implementation of Constructs and package merge in order to implement EMOF. Retaining section 12.3 provide all the information required to fully understand and implement EMOF without requiring the reader or implementer to know anything about package merge.
Resolved in FTF. Disposition: Closed, no change