Is there a way to predict the locations of diagrams (or elements) in the model?

Document Generation
1

Hello,
Today I noticed that one of my models had his “interaction::scenarios” inside a package, and not inside the “viewpoint::DRepresentationDescriptor” as expected.

Same thing happened here, remember: No error message, but Schema Image does not appear - #12 by KaBe
I quote : “BTW I didn’t knew it was possible to create a LAB on the LogicalComponentPkg”

Same happened to me today, my scenarios are inside a “CapabilityPkg”. In short :
’ viewpoint::DRepresentationDescriptor.allInstances()->select(re | re.target.oclIsKindOf(interaction::Scenario))’ does not work for one of my models, It’s because the diagrams are not inside the descriptors xml tags.

One way to know for sure where they are located would be to check the xml code or to do multiple .eContainer()'s.
In the case of the LABs on the previous post, the solution was to go get them inside the “structure” element, which was reffered at with the word : “ownedLogicalComponentPkg”. While it’s class was: “ctx… SystemComponentPkg”.

For the second case (this post), i was able to find the right reffering word. One solution was to add the prefix “owned”. I checked the simplified capella metamodel but that term (ownedAbstract…) was nowhere to be found out there. So that’s one of the tricky/difficult things to handle as a newcomer. I am not anymore, so I was able to handle it, thanks to all feedback on this forum.

Question:
Is there a way to “predict” all the places where a diagram could be “placed” in the model? (Example LAB being in LC PKG rather than the expected placement, and interaction scenario in the capability pkg rather than in the viewpoint::…descriptor)

Thanks.

  1. Edit: I am trying to make a template that can be used by all kind of models, what would you suggest to me, should I consider having 2 blocs of M2DOC codes, one working for LABs located in their usual place, and ther other in the component pkg? (For Scenarios, it would be one code checking scenarios in the viewpoint::…descriptor and the other in the capability package), could there be a third place still unknown? Could they be simultaneously in both places? I know this is a very complexe question.

  2. Edit2: following the same principles as the one mentioned in the previous post, this code should work right

selection.ownedArchitectures->filter(la::LogicalArchitecture).ownedAbstractCapabilityPkg.eAllContents().representationByDescriptionName(‘Exchange Scenario’)

or maybe:
selection.ownedArchitectures->filter(la::LogicalArchitecture).ownedAbstractCapabilityPkg.eAllContents().representationByDescriptionName(‘Interface Scenario’)

image
Inside the service we could try: (Component Interfaces Scenario) and /or (Functional Scenario), such as:

selection.ownedArchitectures->filter(la::LogicalArchitecture).eAllContents(la::CapabilityRealization).representationByDescriptionName(‘Functional Scenario’).asImage()
Nothing.

I will try again, but these trials were not successful, don’t know yet.

By the way this is my favotire place in the forum, and the less frustrating, as there is always someone available to help! Thanks again.

2

I think you typed viewpoint::DRepresentationDescriptor instead of some package element of Capella. DRepresentationDescriptor don’t contains any elements from Capella, they are only referenced.

The element referenced as the target by the DRepresentationDescriptor is the element selected when the representation was created.

You can open the odesigns and look for the representation description of you diagram to see what type of elements are supported as root element. To do so, you might need to install the specifier feature form Sirius.

  1. I think it is always better to reuse the same code as much as you can. Some ideas to achieve this:

     viewpoint::DRepresentationDescriptor.allInstances()->select(re | re.target.oclIsKindOf(interaction::Scenario) or re.target.oclIsKindOf(pkg2::Type2))

 selection.ownedArchitectures->filter(la::LogicalArchitecture).ownedAbstractCapabilityPkg.eAllContents({interaction::Scenario | pkg2::Type2}).representationByDescriptionName(‘Exchange Scenario’)

Where pkg2::Type2 is a type found in the odesign. You could also use the last code without the filter, it will just be a bit slower. You can of course combine more than two types if needed.

In short using only the name of the representation description is a bit slower but might be easier to write and maintain if some types change in Capella. Filtering needs to have a look at odesigns to filter on the right types but is faster at generation time especially on big models.

In both cases this should help you factorize your template.