To find a missing nsURI, usually we use this query:
However i found myself wondering about one particular nsURI that could not be identified through this method (as far as i know), i am wondering what is the best method to debug my M2DOC queries in general. The following debug method is explained:
Goal : [Get access to requirements (using the Capella Requirement addons)]
First Try :
No result, this message appears:
INFO: Empty collection: Nothing will be left after calling eAllContents: EClassifier=SystemEngineering can’t contain EClassifierLiteral=Requirement direclty or indirectly (9, 49)
(Btw there is a typo in "direclty" in M2DOC 3.1.0)
Google research + forum research, i found this :
https: //github. com/ ObeoNetwork/M2Doc/issues/276 (2018 topic)
The answers would not help for my specific need.
Let’s try to check the interpreter again:
Does work find, but only if it’s called from a CapellaModule Eclass.
One solution would be to get the CapellaModule from the self variable and then call the requirements.
We can check the tree /structure of our project to get helped:
We want “test Reqq”.
We can ASSUME that it is under the architecture
First method to get into it would be:
And analyse the results.
Except the interpreter would not work correctly here, it would not accept “eAllContents()” or “eContents()”, it accepts “eClass()” somehow though. No error message for eContents() by the way.
Let’s try another method:
Still not working. Same previous message + 1 error message.
Let’s keep looking, the researches led me to 2 paths:
- https:// forum. mbse-capella. org/t/error-eclassifier-requirement-is-not-registred-in-the-current-environment/4784
in this topic, a problem of nsURI is mentioned. Fair enough, using the method mentioned at the beginning of this topic, i was able to find 2 missing nsURIs:
my query is still not working.
- The problem might be related to types or supertypes and all the EMF eclipse hidden structures? I could experiment with : “oclAsType()”, some experiments:
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement).name = ‘Requirements’)
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement).name = ‘CapellaModule’)
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement).eClass().name = ‘CapellaRequirements::CapellaModule’)
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement).eClass().name = ‘Requirements::Requirement’)
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement) = ‘Requirements::Requirement’)
selection.eContents(capellacore::NamedElement)->at(3).eContents()->select(a|a.oclAsType(capellacore::NamedElement) = ‘CapellaRequirements::CapellaModule’)
These are probably all wrong, and most importantly useless because any additional “capellacore::NamedElement” experimentations i did, would not include the requirements.
(by the way: at(3) is the Logical Arch we see on the image)
The message I got from the intepreter was however very interesting:
WARNING: EClassifier=ElementExtension is not registered in the current environment (76, 77)
This would finally lead me to this topic :
Problems accessing fields (2020 topic)
Finally this nsURI is mentioned : “http://www.polarsys.org/kitalpha/emde/1.0.0”
This was the missing one. My queries work ! (Accessing to CapellaModule then access to Requirements::Requirement).
No Matter how I would have used “self.eClass().ePackage.nsURI” tool, I would have never guessed the missing “emde/1.0.0” nsRUI, Was there any method to find it? I am genuinly curious because this could save me some time in the futur.
Why would :
not work directly? (selection is pointed at the usual self element)
Why do I have to access to CapellaModule FIRST, then be able to call eAllContents(Requirements::Requirement).
The image attached to this post, shows clearly that Requirements elements are located on the tree at the end (UNDER the tree).
The self parameter or selection (pointed at the the system engineering element), is clearly located ABOVE it. Would not “eAllContents(Requirements::Requirement)” be supposedly enough to call the requirements elements? If it’s possible to “call” the requirements without entering the CapellaModule shown in the image. If so, how could that be done?
- Let’s go back to oclAsType() function, you said in the a previous post that :
EStructuralFeature (EAttribute and EReference) have a type. This type is used by AQL after the navigation of this segment of the expression (in your example source) to know what can be called next. In some cases this type can be more generic (a super type) than the type of the element you expect, in that case you can add a cast with the oclAsType() service. It will tell AQL at this point I have a more specific type and access EStructuralFeature or services defined on this specific type. If at runtime you have an element of a more generic type it will produce a runtime exception
From my understanding, in Capella/eclipse the “layers” of classes are not limited to 2 (Eclipse model + Capella Metamodel) ? This means there are types/superTypes and maybe even more.
A simple request from me, if that is possible, could you or someone share some sort of diagram/image / paint to show how the SuperClass, class and capella element interact? Sorry this might seem as a ridiculous request for someone who is expert on EMF and Capella Ecore…
Another example with oclAsType(capellacore::NamedElement). Actually, this can be used to call the PARENT of a function, and check on of its paremeters.
m:for FunctionAnaly| …
m:let FParent = FunctionAnaly.eContainer()
In this particular case, the parent’s parameter of that function, can only be extracted with oclAsType(capellacore::NamedElement),
Does that mean, we are “selecting” from different types of classes returned from “eContainer()” only those that are Capella related. Does it mean that eContainer() returns many classes somehow?
(Finally: the method I used to debug, using several tools in hand + google /forum research, do you think there is a better optimal solution for debugging here in M2DOC? Any other tips? Thanks)