A colleague asked me if OCL had a getType function in the standard library that could be used to get the type of an object.
The answer, AFAIK, is no. There are the oclIsKindOf(Type) and oclIsTypeOf(Type) functions to test whether an object is instance of a given type and the oclAsType to do type conversions but I don´t think there is one to get the type of the object.
Anyone knows whether this function exist? (even if it´s not as part of the standard but provided in OCL implementations). If it doesn´t, any idea why?
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
OCL Specification 2.3.1, p. 147:
“oclType() : Classifier
Evaluates to the type of which self is an instance.”
Thanks! I had missed it somehow. One less problem to deal with 🙂
Or one more: I rarely see the real value of such reflective/type-recursive capabilities apart from writing frameworks and such. Polymorphic dispatch/multimethods or even an old-fashioned instanceof-type type check are typically much better ways to act on actual/runtime types than to make your type system recursive. (IMHO)
What’s the actual use case in your context?
In my case, this is basically syntactic sugar. My colleague wants to formalize in OCL some WFRs she believes that should be added to the UML standard
WFR? In any case, I’m prone to say that UML is the real problem here 😉
That´s why my colleague wants to help improving it 🙂 (to give more context, she detected some missing well-formedness rules when writing action-based operations in the context of her research: https://modeling-languages.com/lightweight-verification-of-executable-models/ )
Jordi,
Beware because this function is not well defined, despite it is included in the latest versions of the OCL standard. In UML, an instance may have several types (and classifiers) and therefore that function should return a set of classifiers and not just one. If the function has to return only one, which one is it?
Antonio.
Good point Antonio!
oclType is used in OCL Specification version 2.3.1 to define other functions:
p.147:
oclIsTypeOf(type : Classifier) : Boolean
Evaluates to true if self is of the type t but not a subtype of t
post: self.oclType() = type
oclIsKindOf(type : Classifier) : Boolean
Evaluates to true if the type of self conforms to t. That is, self is of type t or a subtype of t.
post: self.oclType().conformsTo(type)
p. 160:
flatten() : Set(T2)
Redefines the Collection operation. If the element type is not a collection type, this results in the same set as self. If the
element type is a collection type, the result is the set containing all the elements of all the recursively flattened elements
of self.
post: result = if self.oclType().elementType.oclIsKindOf(CollectionType) then
self->iterate(c; acc : Set(T2) = Set{} |
acc->union(c->flatten()->asSet() ) )
else
self
endif
p. 165:
flatten() : Sequence(T2)
Redefines the Collection operation. If the element type is not a collection type, this results in the same sequence as self.
If the element type is a collection type, the result is the sequence containing all the elements of all the recursively
flattened elements of self. The order of the elements is partial.
post: result = if self.oclType().elementType.oclIsKindOf(CollectionType) then
self->iterate(c; acc : Sequence(T2) = Sequence{} |
acc->union(c->flatten()->asSequence() ) )
else
self
endif
It seems that for the authors of the Specification oclType is already well-defined.
So I guess we´ll need to ping the guys from the OCL standard spec and ask what´s their interpretation.
oclType() is indeed a funny, and has changed in each version of the OCL 2.x standard.
My proposal is contained in Section 5.2 of:
http://www.eclipse.org/modeling/mdt/ocl/docs/publications/OCL2011ModelingOCLstdlib/ModelingOCLstdlib.pdf
This proposal is working in the Juno release of Eclipse OCL; except that the spelling of Class is temporarily AnyClassifier pending full-alignment with UML names.
The fully reflective tower works.
In regard to multi-types, I have had some discussions with the MEF (http://www.omg.org/cgi-bin/doc?ad/11-06-22) team in which I hopefully removed the need for semantic changes to OCL. It appears that in OCL (but not in MOF) an object always has a current statically determined self type which determines the names that may be used for navigation from self. In accordance with this static determination, there is a dynamic leaf subtype which oclType() returns. There is also a set of alternate leaf types (and their supertypes) to which self can be cast using oclAsType(). It is therefore only necessary to add an oclTypes() function to return the set of (dynamically) available leaf types for self. OCL functionality does not need to change, just a few definitions get clarified. This is an intuitive conclusion; I welcome academic confirmation/contradiction.
Dear all,
I double-checked in the UML spec (metamodel), and it is true that an element can have only one Type (multiplicity is 0..1). However, it is also true that an object can have many classifiers (the multiplicity in the relationship between InstanceSpeciafication and Classifier is “*” at the Classifier end). Finally, Classifiers are Types (there is an inheritance relationship between them).
In any case, I think the (practical) problem still remains: when a UML modeller draws an instance “o” and assigns two classifiers (“A”,”B”) to it (“o:A,B”). Which is its “type”? what should the oclType() return in this case? In my mind, both classifiers act as “types” for the object.
I fully concur with Ed and its solution, and with his claim that some clarifications are required. At least, it could be good to understand how to select (if possible?) the classifier that the modeller wants to act for the “type” of an object.
Besides, I’d personally prefer not to have the restriction that an object can only have one type, although it can have many classifiers. And if an object has multiple types, I think there should not be any problems with the navigation from “self”, because a constraint/expression is always interpreted in the “context” of a given classifier. But maybe I am mistaken…
Anway, this could be an interesting discussion topic at the OCL workshop at MODELS 🙂
Antonio.
Hi Antonio
I wasn’t aware that UML already has multi-classification.
For static multi-classification, one could imagine some enhanced multi-type for self that could use names from more than one type tree, but ambiguities are a bit frightening. Do they disappear in a library operation, and reappear when the library operation calls back to overloaded operations?
For dynamic multi-classification, static analysis of the dynamic name visibility is not possible, so casting is unavoidable.
Clearly this is a UML/OCL mis-alignment, but one with a nice easy solution; keep OCL’s single typing and require the OCL-invoking functionality to present the SMOF sub-object that corresponds to the static type of the OCL invocation. Alternate SMOF sub-objects are accessible via oclAsType and oclIsKindOf.