AppliedMetamodel from a Diagram View

[Yves.Carrier.Videotron]

Hi there,

I found out recently that a major problem I had in controlling the QuickLinker behavior is related to the current Diagram AppliedMetamodel. If you struggled in the same areas as I did within the Sparx documentation, you probably noticed that this "link" is not obvious when defining an MDG technology that should control the QuickLinker behavior. Having said that, I did not find a mean of controlling the default AppliedMetamodel that is applied to a Diagram Type generated from a "view specification". As a result, when I create a new Diagram from the Diagram View I created, the AppliedMetamodel is the actual View Profile that I defined that is containing very little. And if, for instance, I created a <<metarelationship>>, I can acces to the result of it only by changing the Diagram's AppliedMetamodel to "Complete", which obviously leads to confusion and which is not acceptable from an end user perspective. So, how could I control the AppliedMetamodel to be set to "Complete" automatically?

Thanks for your help!

[Eve]

The default is always 'Default', which shows quicklinkers that match the current toolbox. So the easy solution is to add to the toolbox. (Which also means that you aren't forcing your users to use EA only through the quicklinker.)

When a user tries to use the quicklinker they get the option of turning off 'Filter to Toolbox', which means that they get the complete metamodel in the quicklinker when they want it.

[Yves.Carrier.Videotron]

Thanks Eve,

I will give it a try. But on a wider perspective, is there a resource somewhere that explains the overall behavior of the QuickLinker (ideally an Activity Diagram that would show the decision flow)? Currently, I try to "reverse engineer" this behavior from all these multiple procedures that are described here and there without never feeling that I am fully under control.

Thanks again!

[Eve]

I'm not sure if there's anything quite like what you're describing.

The metamodel relationships allow you to define what is valid and let EA take care of the details of the quicklinker. The behavior of filtering to the toolbox is effectively like the diagram filters in the quicklinker table. The difference is that and end user of your profile can create custom views with any combination of your types and types from other profiles. They aren't constrained by the views you conceived when you developed the profile. (Which goes double for any profile developed by Sparx Systems)

My summary of the process is:
When dragging between two elements, EA checks every defined rule to see if it applies to those elements. It filters the connector types to those in the toolbox (unless disabled) and adds them to a single level menu, discarding any with duplicate text.
When dragging to empty space, EA checks all the rules against the source element. It filters both the connector types and opposite element type against the current filter then adds them to a two level menu. Connector type then element type. Again, it discards any rules that generate duplicates but this time checking both menu levels.