-
Key: KERML-138
-
Status: closed
-
Source: NIST ( Mr. Conrad Bock)
-
Summary:
The signature of resolveGlobal is
resolveGlobal(qualifiedName : String) : Membership [0..1]
while uses of it sometimes apply oclAsType to the result, as in
validateRedefinitionFeaturingTypes let anythingType: Type = subsettingFeature.resolveGlobal('Base::Anything').oclAsType(Type) in ...
but Membership isn't a Type. Comparing to the body of specializesFromLibrary:
specializesFromLibrary(libraryTypeName : String) : Boolean body: let mem : Membership = resolveGlobal(libraryTypeName) in mem <> null and mem.memberElement.oclIsKindOf(Type) and specializes(mem.memberElement.oclAsType(Type))
I gather a memberElement navigation is needed, as in
let anythingType: Type = subsettingFeature.resolveGlobal('Base::Anything').memberElement.oclAsType(Type) in
Searching on "resolveGlobal" finds quite a few missing memberElement s, eg, validateSubsettingFeaturingTypes, checkStepSpecialization, checkOperatorExpressionSpecialization, maybe others.
-
Reported: KerML 1.0b1 — Thu, 3 Aug 2023 14:09 GMT
-
Disposition: Resolved — KerML 1.0b2
-
Disposition Summary:
Correct uses of resolveGlobal
Taking into account changes from previously adopted issue resolutions, the problem identified in the issue needs to be fixed in the OCL for the following constraints:
- validateSubsettingFeaturingTypes
- checkOperatorExpressionSpecialization
- checkFeatureValueBindingConnector
- checkMetadataFeatureSemanticSpecialization
-
Updated: Tue, 1 Jul 2025 15:01 GMT
KERML — oclAsType applied to resolveGlobal
- Key: KERML-138
- OMG Task Force: Kernel Modeling Language (KerML) 1.0 FTF