I understand that the core Obeo team cannot reply to all posts here so I hope that the Capella community can help here:
capella_query_by_name(myClass, "Typing Elements") returns Property objects so I’d like to get the Class object that I see in the Semantic Browser.
What would be the method to apply on the returned object?
Thank you.
This call returns a Class object 
Using the Semantic Browser on the different Class in your model, you should see when capella_query_by_name(myClass, "Typing Elements") returns Properties or Class objects (it depends if the association/generalization is leaving or arriving on your Class).
The reason why your code was not working is because in:
for aTypingElement in typingElements:
print(aTypingElement[0].get_type())
should be
for aTypingElement in typingElements:
print(aTypingElement.get_type())
since aTypingElement is not an array but the element in your loop lopping on an array.
Strange design choice.
What if it returns a Property? How can I navigate to the Class object?
Finally, Obeo may not answer all questions, sometimes we may not have time, but also we do not know all answers!
I have tried both syntax
Maybe Associations, regardless of the incoming/outgoing direction, are in Properties while Generalizations are in Classes?
First of all: Please be aware that I do not know exactly what you are trying to do. I am answering some of your questions, but lacking of context, I may not have all the best answers.
For example, in this post How to get the associations between classes with Py4C? - #18 by StephaneLacrampe I am giving options because the e_inverse that was suggested was not working.
If you want to navigate associations and generalizations between classes, there are 4 things to navigate: associations that leave, associations that arrive, generalizations that leave, and generalizations that arrive. For that, I believe that using the Semantic Browser queries is the easiest for you as it avoids you from having to navigate all detailed Capella objects. In theory, if the Python4Capella simplified API was complete on this part of the Capella meta-model, you should not have to go through these queries. But this is not the case, hence the solution I proposed.
So, the easiest way for you to see what queries you should call is to create 4 classes, with one association and one generalization between each pair, and see what the queries return by clicking on each class with the Semantic Browser view open. I would also make sure that make visible all model elements in your project explorer so that you have more detail on the model structure (in the project view, select “Quick Filter->Deselect All Filters”)
I see 4 queries corresponding to your need:
If you look at what items (2) and (4) are giving as results in the Semantic Browser, you’re going to get Classes, so you’re good even if these are 2 different queries.
If you look at items (1) and (3), the queries and give you a Property as a result. If you want to get the Class out of a Property, you can use get_type()
I hope it helps.
Stephane LACRAMPE
Please note I modified my initial previous response.
Please also note that there are other types of associations between Classes (Aggregation, Composition) and also that there are ways to create Properties in Classes. I do not know precisely how it all works, so some of the code you are writing for navigating Associations and Generalizations may fail when adding these other concepts to your model. It would need some testing to see how these other elements affect the queries results.
You wrote
If you look at items (1) and (3), the queries and give you a Property as a result. If you want to get the Class out of a Property, you can use get_type()
get_type() is returning a class but the same class I am navigating from. So how, from the Property, I could navigate to the other side of the association?
Hum, strange. Can you share your code?
My mistake. The name of the object returned by aTypingElement.get_type() in the code below is the same name as the class (e.g. aClass in the code below).
Once you have the TypingElement object (e.g. anObject in the code below), how do you navigate to the class which is in the other side of the association? Tx
typingElements = capella_query_by_name(aClass,"Typing Elements")
print (str(len(typingElements)) + " typing elements")
for aTypingElement in typingElements:
print(aTypingElement)
anObject = aTypingElement.get_type()
print("anObject[0].get_name(): " + anObject[0].get_name())
What is making this difficult for me is that I am not able to make the debugger working with Py4C.
Indeed, if the debugger were working, it would be easier.
What you should use is the Semantic Browser view; click on your class in the project explorer view or in your diagram, and make sure you have the Semantic Browser view opened; you will see what the results are given by the queries you are using, this should help you to understand what is going on.
Also, you are struggling because the API of Python4Capella is not complete on this part of the model; if it were, this would be much easier.
Anyway, your code is correct, but this code is for case (3 - arriving association), and you are testing it on a Class with case (1 - leaving association). The tricky thing is that both queries give you a result when in case (1), so you would have your code to test if both queries give a result, and if the Typing Elements one gives you the same class, this means that the association is leaving.
I hope this helps.
Stephane
Thank you Stéphane.
It would very helpful if the authors of Py4C publish a working code for a basic class diagram with 3 classes and the 4 cases that you are describing.
Yep and we are open to contributions too!
@StephaneLacrampe Honestly, I am totally lost in the way to get the associations with Py4C, how Properties relate to associations and how to query Typing Elements and navigate from them.
imho, the Py4C team should publish a sample code.
Well, we are thinking about completing the API so that navigation is much easier for the data modeling part. Still, I don’t know if this will happen and when, hopefully in a few months.
We have spent 10x the time it would have taken for the Py4C to develop a working sample code with the current API.
Thank you anyway for your time.