Author Topic: Linking from structures to type block diagrams  (Read 821 times)

patrick j.

  • EA Novice
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Linking from structures to type block diagrams
« on: November 20, 2020, 02:22:05 am »

I have in DDS modelling a IDL::IDLStruct with two Attributes, one a key (name="head", type="Header") and some idlField. When it comes to the key, I have some block diagram, defining the actual "Header" type, including some internal block diagram.

What is a good way of linking an attribute of some structure with a well defined type to the corresponding block diagram of this type? When changing properties within the type, these modifications are properly forwarded to the attribute, but the other way round is difficult, find the type definition diagram from the attribute itself.

Best regards!


  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Re: Linking from structures to type block diagrams
« Reply #1 on: November 20, 2020, 08:45:33 pm »
Hi Patrick,

Wow, DDS eh? That takes me back. Glad to see someone's using it. :)

Unfortunately, what you want doesn't really have any support in EA.

... linking an attribute of some structure with a well defined type to the corresponding block diagram of this type?
The problem is that EA is not aware of any one single diagram associated with any element. While you can locate the classifier element which is used as the attribute's type, EA doesn't have a concept of a particular diagram which defines that type.

So it's not something that exists in vanilla EA, but it is quite possible to achieve something like it.
Here's an outline of a solution:
  • In the model, you need to add the type-definition diagram's GUID to a tagged value (call it "Definition diagram") in the type element (eg Header).
    You can do this manually every time, or you can create a stereotype which auto-creates the tagged value whenever an element of that stereotype is created. Either way, you must remember to set the value to the correct type-definition diagram's GUID once you have created that diagram.
  • To enable the lookup, you need to construct an Add-In.
    This is because a diagram-context script can only distinguish elements and connectors, it doesn't recognize that an individual attribute is selected in the diagram. But an Add-In can recognize that fact.
    • In the Add-In you need to store the currently selected attribute by handling EA_OnContextItemChanged().
    • You also need a diagram-context menu item "Type definition diagram" or similar.
    • When the menu item is triggered, the Add-In retrieves the diagram GUID stored in the attribute type element's tagged value, retrieves the diagram's properties from the database with Repository.GetDiagramByGuid() and opens the diagram using Repository.OpenDiagram().
      You need to retrieve the properties because OpenDiagram() takes a long, not a GUID, but it's more robust to store GUIDs in situations like this.
As an alternative to creating a tagged value, you could conceivably use composite diagrams. Each element in EA can have one (1) composite diagram, and that diagram has some special handling associated with it so it's easy to retrieve from the API and so on. However, this assumes that no type-definition diagram defines more than one type, because two elements can't share the same composite diagram.
(Well, technically they can, but it's not intended use and it can have nasty side effects -- deleting an element also deletes its composite diagram, and if that diagram happens to be the composite diagram of another element then that other element loses its composite diagram. This is probably not what you want, so it's better to go with a tagged value even if you do have to copy-paste a lot of GUIDs.)

The Add-In could also include some support functions to reduce the amount of GUID copy-pasting, clear the tagged values targetting a certain diagram when that diagram is deleted (or indeed prevent the deletion of said diagram if it's the target of an element's tagged value), etc.

You could also just locate the type element, rather than the type-definition diagram, and then use EA's built-in "Find in Diagrams" function. This would obviate the need for tagged values storing the type-definition diagram GUIDs.
However, you'd still need the Add-In because the crux is once again that only an Add-In can be aware of what attribute the user has selected in a diagram. Also, if the element is present in more than one diagram, the user would be presented with a selection dialog and then need to select the correct one.
So that would be a simpler solution that does not introduce any tagged values (which need maintenance as the model changes over time), but at the cost of a less smooth user experience.



PS Why yes, I am available to build this for you. ;) Hit me up with a PM if you'd like a quote.
My theories are always correct, just apply them to the right reality.

patrick j.

  • EA Novice
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: Linking from structures to type block diagrams
« Reply #2 on: November 24, 2020, 02:16:28 am »
Hi Uffe!

Thank you very much for your detailed answer! While an add-in definitely seems like an ideal approach to make this feature work in a proper way, your second idea regarding the composite diagram looks charming to me, as well... I am just trying to use the composite approach, and so far I am pretty happy. Let's see, if this approach can scale properly and my colleagues understand what I am trying here ;-)

Best regards,