Extracting Available Element Types in Add-In

[Murat]

Hey guys,

I would like to enable users of my Add-In to have a dropdown menu within the Add-In that provides them with all (for them) possible diagram elements (Actor, Use Case, State, Activity and so on) from UML, SysML, and BPMN for selection.

My idea was to retrieve the version of Enterprise Architect that the user is using and based on that, extract the available element types to later utilize these types in the "repository.elements.AddNew(Name, type)" function. However, I am facing two challenges: I don't know how to retrieve the version within the Add-In, and I'm unsure how to extract the element list based on that version.

Therefore, what I need is a list of possible "UML metaclass types" and "fully-qualified metatypes defined by an MDG Technology" for SysML and BPMN.

I would appreciate any guidance on how to approach this issue or if there is a better alternative solution available.

Thank you in advance for your help!

[qwerty]

You can't really extract the toolbox content. You would need to read and parse the corresponding MDG which is not always available. If so, parsing it will give you headaches. Probably you have to hard-code  you menu. Question: why? If you have a good answer: go ahead. Else: teach them to use the toolbox which is adaptable flexibly.

q.

[wivel]

I'm with qwerty on this one. Your time end energy is much better used on educating and teaching the users how to use the toolbox and which elements to use, than on going the MDG way. Taking the MDG path will mean time spend to develop and maintain and it will not guarantee that the users use the regular toolboxes anyway.

Henrik. 

[Murat]

You can't really extract the toolbox content. You would need to read and parse the corresponding MDG which is not always available. If so, parsing it will give you headaches. Probably you have to hard-code  you menu. Question: why? If you have a good answer: go ahead. Else: teach them to use the toolbox which is adaptable flexibly.

q.

Thank you for your response! This is the problem I am facing now:

I want to provide users with their own MDGs the capability to have my tool recursively scan and extract the types and stereotypes of the elements within the project. The goal is to store these types and stereotypes and make them available to users later, allowing them to create new elements. I understand that the selection will be limited to the elements that have already been created but that's fine.

Now, I have a couple of questions that I hope you can help me with:

For creating elements within these custom MDGs, do I only need the type name and stereotype name in the format "Technologyname::Stereotype," or is there more information required?

My second question is related to extracting the technology name. When I use element.StereotypeEx to retrieve the stereotype name of the elements, it returns only the stereotype without the technology name. How can I obtain the technology name as well?

The reason I'm trying to do this is to allow users to import elements from another tool and specify as which element type and stereotype these imported elements should be recognized.

[qwerty]

For creating elements within these custom MDGs, do I only need the type name and stereotype name in the format "Technologyname::Stereotype," or is there more information required?

My second question is related to extracting the technology name. When I use element.StereotypeEx to retrieve the stereotype name of the elements, it returns only the stereotype without the technology name. How can I obtain the technology name as well?

The reason I'm trying to do this is to allow users to import elements from another tool and specify as which element type and stereotype these imported elements should be recognized.

1) Basically yes, but making individual tooloxes is a bit more complex overall.

2) If stereotypex does not give the profile name then the stereotype is likely some "wild" one. Have you cross-checked with the stereotype properties?

3) That's probably either a manual task or one done by a script knowing how to transform the one stereo into another.

I can merely sense what you mean, but it looks like it need some analysis to give a meaningful answer.

q.

[Murat]

1) Basically yes, but making individual tooloxes is a bit more complex overall.

2) If stereotypex does not give the profile name then the stereotype is likely some "wild" one. Have you cross-checked with the stereotype properties?

3) That's probably either a manual task or one done by a script knowing how to transform the one stereo into another.

Thank you for your quick response!
So I have an example Project, where I have two "test"-elements. Here you can see the properties of the first element inside EA ("MDG-Test::My Stereotype A"):

Here you can see the properties I am retrieving in my add-in ("My Stereotype A"):


I still haven't found a way to read the technology name (in this case "MDG-Test").
The manual, messy way would be to have the user manually enter the technology name in the add-in. From this I could then "build" the stereotypes.
What do you think? Is there a better way to do this?

[qwerty]

Dont mix Technology and Profile. The stereotype shows the Profile. There is no (easy) way to deduct the MDG from the Profile!

Will look into the ex-issue later...

q.

[qwerty]

Yes, sorry. I'm no longer a power user and only comment on my fainting memory. I dug into and yes, the ex ist just something that is useful when setting it where it will accept an FQN (I cant recall the scrappy details of this Sparxian ex-flood which once spammed attributes and operations, but be it as it is). The way to query the profile is this (I'm using my Python framework but you get the gist hopefully):

Code: [Select]

e = rep.getElementByGUID("{AF140849-33B6-47ff-90DC-A737522D547D}") # get some stereotyped element
print(e.stereotypeex)
qres = ET.fromstring(rep.SQLquery("SELECT description FROM t_xref WHERE Client = '{AF140849-33B6-47ff-90DC-A737522D547D}'"))[0][0][0][0].text # just a convenient way to unwrap the XML result from sqlquery
print(qres)

and that spits out:

technical issue
@STEREO;Name=technical issue;FQName=my profile::technical issue;@ENDSTEREO;

So you need to parse the csv txt from Description and you find "FQName=my profile::technical issue;"
Here "my profile" is the profile name or you can use the FQN (which I expected to come out of steretypeEx) "my profile::technical issue"

q.

[Murat]

Yes, sorry. I'm no longer a power user and only comment on my fainting memory. I dug into and yes, the ex ist just something that is useful when setting it where it will accept an FQN

....

q.

That works perfectly. Thank you very much!
I parse the profile name via regex with "FQName=([^:]+)" (or the whole FQN with "FQName=([^;]+)") and it does its job 

How did you figure that out? Is there some kind of documentation for the SQL tables?

[qwerty]

Look into my Inside book. I put in quite some effort some years ago (when I was much more involved with EA). I would guess that most of the people here dealing with SQL have a copy.

q.

[qwerty]

Now that memory comes back - sorry again - there's Element.FQStereotype

:-/

q.

[workingmatt]

I was hoping to beat qwerty remembering element.FQStereotype!

The types of elements and relationships in an MDG are listed in the Resources window. There's a Repository.Resources collection/array but I think that's to do with the project management of a model type of resource. If you can find a way to interrogate the Resources (Configure->Reference Data->Resources) you might find your answer.

[qwerty]

Sorry for being too fast ;-)

Forget the Refernce Data. This is completely in EA's memory. No chance except you knw their internal memory data structures. In order too keep a working brain for the rest of my days I will not look into that (though I disassemble a bit of the code in the past).

q.

[philchudley]

You can extract the fully qualified stereotype including the MDG name from the dreaded t_xref table

XrefID,Name,Type,Visibility,Namespace,Requirement,Constraint,Behavior,Partition,Description,Client,Supplier,Link,

{B8B468ED-8D4F-415c-8130-9108013D6A2C},Stereotypes,element property,Public, , , , ,0,@STEREO;Name=FunctionalRequirement;FQName=EAREQ::FunctionalRequirement;@ENDSTEREO;,{00196C9C-8221-4405-A5C3-616FC03FAA52},<none>, ,

The t_xref column is Description and the FQ stereotype is held in a; delimited string, for example FQName=EAREQ::FunctionalRequirement;

So, to discover the MDG for a particular element (or connector)

1) Create a SELECT query that extracts t_xref.Description from the join of t_object and t_xref, using t_object.ea_guid and t_xref.Client
2) Extract you MDG by extracting the necessary substring.

An example of a SQL query to perform the above (without the substring extraction) is:

SELECT t_xref.Description
FROM t_object, t_xref
WHERE t_object.ea_guid = t_xref.Client
AND t_object.ea_guid = 'GUID of your element /connector here'

Other methods of joining tables are available 

Phil

[qwerty]

Phil,
that's pretty much what I wrote above. However, this does NOT give the MDG but the PROFILE name! Often they happen to be the same but actually they are not. Besides, the FQStereotype returns the value more easily :-/

q.