Legacy Issue Number: 8695
Source: SAP SE ( Axel Uhl)
MOF has always lacked the capabilities to navigate an association
qualified by the values of properties of the end to which to navigate.
This has been a feature in UML since at least UML 1.3. When implementing
MOF, this leads to the unpleasant effect that in order to pick elements
from a collection returned from navigating a to-many association
requires iterating over all elements returned and filtering for the ones
meeting the desired criteria. The way MOF works, this makes it
impossible to provide an efficient implementation that yet is
Key qualifiers address exactly this issue. However, when the UML was
split into infrastructure and superstructure, this valuable UML feature
was placed into the superstructure, thus not being accessible by the MOF
specification. MOF itself doesn't provide its own approach to qualified
A concrete example of why the current situation is less than optimal is
the UML with its association between Namespace and NamedElement, using
role names "ownedMember" and "namespace." When navigating to a member of
a namespace with a particular name, one has to enumerate all elements
owned by that namespace and compare its name with the name looked for.
The effort scales with the number of elements contained by that
namespace, and there is no way for a repository to provide an efficient
implementation for that in a standard-compliant way.
A fix for this problem would be to move the association from
UML::Classes::AssociationClasses::Property to itself with properties
named "qualifier" and "associationEnd" to
InfrastructureLibrary::Core::Basic and connect it to
InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2
could use this useful feature, and a language binding for MOF2 could use
this to offer qualified navigation. Repository implementations may
provide a naive implementation at least, whereas advanced repositories
may use the opportunity to maintain internal index structures that
facilitate performant qualified access.
I don't know whether this changes anything in the way an issue is
handled by the OMG, but I've already talked to several vendors, current
MOF implementors and active OMG contributors (also see Cc list), and
there is wide consensus that this would be a very helpful change.
Reported: MOF 1.4 — Mon, 11 Apr 2005 04:00 GMT
Updated: Tue, 29 Mar 2016 15:41 GMT