ownedDiagramElements from DRepresentation (M2Doc)

Hello,
I’m trying to generate a document where all my diagrams (at the moment focus first on SDFB) are presented, and which subsequently lists all the associated SystemFunctions of each Diagram.
So far, I’ve managed to display every SFDB as Image:
m:for caps |self.containedSystemAnalysis.containedCapabilityPkg.ownedCa pabilities
m:for im | caps.representationByDescriptionName (‘System Data Flow Blank’)
m:im.asImage().fit(300,200)
When I use the Sirius Interpreter to evaluate which SF are present in each Diagram, I do get the result I need. For example, when I select an SDFB trhough the Model Explorer, and insert the expression below, the names of all the contained SF are displayed:
<%self.representation.ownedDiagramElements.containers.name%>
However, I can’t seem to get M2Doc to lists them in my document, as I get errors stating ownedDiagramElements is not within the EClass of the DRepresentation. I’ve searched online for documentation on the EClass and to see which functions then are supported for the DRepresentation, but this didn’t get me further either.
Any suggestions on how to approach this, or maybe someone knows how get M2Doc to print the ownedDiagramElements.containers.name of an DRepresentation?
Many thanks, and have a good weekend,
Maarten

Hello Maarten,
You are using the DRepresentation in M2Doc witch is the diagram and the semantic element of that diagram in the interpreter. You need the semantic element of that diagram, so you can either use the the caps variable in your first example “caps” or use the target reference of the DRepresentation “self.target” or “im.target”.
regards,
Yvan.

Hello Yvan,
Thank you for your reply. I have been trying to implement your solution, however the Feature ‘target’ can’t be found in my EClass DRepresentation:
Invalid query statement: Feature target not found in EClass DRepresentation
Is there a nsURI that I might be missing?
Regards,
Maarten

Yes you are right you need to add "
http://www.eclipse.org/sirius/1.1.0" to the template nsURIs.

I still get errors even with Sirius/1.1.0 in the template’s nsURIs, see attached screenshots.
target in the DRepresentation is still not found…
The reason I want to do this, is to within a document go from a Capability, to showing the contained diagrams (this case SDFB), and from there describe what is in the shown diagrams (e.g. provide a list of which functions are present, which exchanges, etc.). Perhaps there is another approach that is better than the one I’m currently using?

Also the Feature representation can’t be found in the EClass DRepresentation, as I thought/hoped this would be the same as the AQL Expression that works in the Sirius Interpreter when self is a SDFB diagram (<%self.representation.ownedDiagramElements.containers.name% >).
m:im.name.representationByName(). <—Feature representation not found in EClass DRepresentation representation.name

Try adding both:
"
http://www.eclipse.org/sirius/diagram/1.1.0"
"
http://www.eclipse.org/sirius/1.1.0"
Does it help ?

Hello Maarten,
You will find enclosed a template which list the SFDB diagrams stored under the capabilities (in SA) and list the elements represented in the diagram.
The template uses only one variable: self mapped to the root model element (SystemEngineering).
(I have added all the nSURI related to sirius in the template configuration)
To get the content of a diagram, I use the relation “representationElements” which list all the graphical elements.
Then I add “target” in order to get the model element represented by the graphical element.
Finally, you need to filter the list of elements in order to be able to get attributes of those elements.

  • In order to get the name of the model element, I use the filter “NamedElement” because the attribute name is defined on NamedElements (which is a Capella type of elements)
  • You can also filter based on other Capella types like for example SystemFunction in order to get only the functions (and also uses the relations and attributes of system functions)

Hello Aurelien,
Thank you, this is exactly what I was looking for!

Hello,
This feature is very interesting. But when trying to use it, or to use the given Template to generate a document, I face to this issues:
Invalid for statement: Couldn’t find the ‘representationByDescriptionName(EClassifier=Capability,java .lang.String)’ serviceInvalid for statement: The iteration variable types must be collections ([Nothing(Couldn’t find the ‘representationByDescriptionName(EClassifier=Capability,java .lang.String)’ service )]).
Does I miss Something ? Thank for your reply.

Hello Benjamin,
It may come from the version of M2Doc you are using.
In order to make this example, I used Capella 1.2.1 and used the latest version of M2Doc:
https://s3-eu-west-1.amazonaws.com/obeo-networkaggregation-r eleases/capella-extensions/capella-1.2.x/nightly/full/org.ob eonetwork.capella.update.full.zip

Hello Aurélien,
Thank for your reply. I thought that I had the latest version installed but seems not. With the latest version of M2Doc it’s work better.

Hello everyone,
I post on this topic because my problem is actually quite the same that the one here.
I wanted to list all the Logical components of a diagram LAB, associated with their description.
Following the tempalte that Aurelien did, I only changed ctx::SystemFunction with la::LogicalComponent.
Although it worked perfectly with a LCBD, it didn’t with a LAB.
I then further investigate this issue by diplaying the class of all elements represented in the diagram.
I wrote
{m:for elem | im.representationElements.target->filter(capellacore::NamedElement)}{m:eClass()} which send me back
EClassImpl@58da6f7d (name: Part)
I then could displayed the name of the logical components of the LAB changing ctx::SystemFunction with cs::Part.
However, I can’t have access to the definition of the component from its graphical representation.
Does anyone knows how this can be achieve ?
Regards,
Julien

Hello Julien,
Actually it’s a bit technical…
In Capella, there is two different type of elements: the components and the parts

  • a component is the definition of a type
  • a part is an instance of a component
    This distinction comes from SysML (which forces to define types then instanciate them).
    Capella implements these 2 types of elements in order to ease interactions with SysML tools.
    However, it has been decided to hide this distinction in Capella to ease the understanding by users.
    (Indeed, software designers define types then instances. However system engineering often works with one instance, or specific types for each instance, so this distinction was not necessary)
    So actually, what you see in diagrams is not components but parts (instances).
    If you use the relation “abstractType”, you will be able to navigate from the part toward the component.