-
Key: KERML_-165
-
Status: closed
-
Source: The MathWorks ( Mr. Alan Moore)
-
Summary:
In section 8.3.2.4.5 - the spec says
{redefines memberName}
A Namespace can provide names for its members via the memberNames and memberShortNames specified by the Memberships in the Namespace.
However, the only subclass of Membership, OwningMembership redefines memberName, thus:
8.3.2.4.8:
/ownedMemberName : String [0..1]Presumably this means that effectively memberName must equal ownedMemberName in OwningMembership.
There is no constraint to this effect and i can see it would be tricky, give the redefinition.
I wonder whether the metamodel needs a bit of surgery, given that the majority of Memberships are OwningMemberships and therefore have this issue. -
Reported: KerML 1.0b2 — Sun, 9 Feb 2025 11:56 GMT
-
Disposition: Closed; No Change — KerML 1.0b4
-
Disposition Summary:
No change
By UML semantics, redefining a property means that it replaces the redefined property in the redefinition scope. Therefore, in the case cited in the issue, there is no need for a constraint, because OwningMembership doesn't even have a memberElement property. The owningMemberElement property is the memberElement property in the context of OwningMembership. If an OwningMembership element is "upcast" to its Membership supertype, then accessing the memberElement is just the same as accessing owningMemberElement on the element considered as an OwningMembership.
Property redefinition is used extensively in this way in the KerML abstract syntax model (as it is in most MOF-based abstract syntax models).
-
Updated: Sat, 19 Jul 2025 18:59 GMT
KERML_ — Use of memberName in OwningMembership
- Key: KERML_-165
- OMG Task Force: Kernel Modeling Language (KerML) 1.0 FTF 2