Messages

1

General Board / Exporting EA model into HTML - Browser Compatibility Issues

« on: March 01, 2021, 08:49:26 am »

Hi,

I'm looking for a way to export my EA model into HTML so I can share it.
I've been using the Publish > HTML option.
I have been finding (as other have reported https://sparxsystems.com/forums/smf/index.php?topic=17655.0 and https://www.sparxsystems.com/forums/smf/index.php?topic=38894.0) that I cannot use the HTML files easily.
My problem is that the likely audience for my files are not going to want to install IE11 or add extensions.
Is there any way around this?

2

Automation Interface, Add-Ins and Tools / Re: Improving performance of loading large data into an EA Model

« on: December 08, 2020, 08:52:50 pm »

Hi qwerty,
We have a process that creates tables of objects that represents our model - this is then migrated to EA UML.
The migration creates classes, stereotypes, connectors, attributes, operations, proxy connectors, diagrams (including objects and links).  It may be extended to other object types.
We are a little nervous about manipulating the underlying tables in EA directly as we feel the EA Automation Interface is more stable, i.e. EA could change the structure of the underlying tables without warning.
Andy

3

Automation Interface, Add-Ins and Tools / Re: Improving performance of loading large data into an EA Model

« on: December 08, 2020, 01:13:16 am »

Uffe and qwerty,
Many thanks.
As you have both mentioned, retrieving data from a model is best done (for performance reasons) using SQL queries, and this is what we do.
The performance issues arise when we want to create objects.  And both your comments agree with our findings.
For clarity Uffe, the two approaches we were testing were to start with a dataset of objects we want to migrate into EA.  Approach one was to create these in EA using the EA Automation. Approach two was to create a Native XML file programmatically based on the objects we want to create and import this file into a Model.
We definitely take onboard your suggestion of switching to SQL Server.
Andy

4

Automation Interface, Add-Ins and Tools / Improving performance of loading large data into an EA Model

« on: December 04, 2020, 05:26:08 am »

We have a big model to load and so we ran some performance testing - we summarise the results below.
It would be really helpful if people could tell us whether these results fit with their experience. And also share any tips for further improvement? 

We have a model that we are trying to load in EA, currently using an MS Access Database EA Project but as we reach the limit of Access we will move to an SQL Server EA Project. It has: 14284 classes, 42725 attributes, 57065 connectors, 28483 proxy connectors.
Our first attempt at loading using EA Automation took 18 hours to load this full model.  We then found this link: https://sparxsystems.com/forums/smf/index.php?topic=4143.0 and by using the performance flags (BatchAppend, EnableUIUpdates) this took the time down to 6 hours.  We noticed here that we were calling the interface to retrieve created objects (e.g. repository.GetElementByGUID()). By storing the objects locally instead we got the time down to 3 hours.  Also, there appears to be no difference between using the internal VBScript or the external EA Automation.

We also tried another approach of using Native XML through the ImportUsingXMI command.  This only took 15 minutes to run.

We then looked at trying to compare the performance of these techniques, comparing the simple task of how long it took to load a number of classes into a package.

The table below shows the results of this comparison.
The values of the right-hand three columns are average times to load a class in milliseconds.  As you can see, when the performance flags are off the time grows linearly with the increase of classes, for the other two it is roughly constant.

Number of Classes                             Flags off                           Flags On                   NativeXML
1000                            12                 5                 8
10000                           21                 5                 4
20000                           34                 5                 9
30000                           47                 6                 6
40000                           62                 5                 6
50000                           78                 5                 7
60000                           91                 5                 11
70000                           106                6                 10
80000                           119                6                 10
90000                           135                5                 11
100000                          152                6                 12

It looks like the 'Flags On' approach is the best, but when we have a more complicated model than just classes in a package (see times above) then the 'NativeXML' approach is better.

5

Automation Interface, Add-Ins and Tools / Re: Python Automation Interface - EA.Interop Development - alpha project

« on: November 13, 2020, 08:26:51 pm »

Hi Geert,
This looks really good.  We are in the process of writing a wrapper to this project that hides the simple API and as you say creating an enhanced API for our specific needs.  It would be good hide the simple API in its own project with the original names (to help porting).  I will pass this back to the team.
Many thanks again,
Andy

6

Automation Interface, Add-Ins and Tools / Re: Python Automation Interface - EA.Interop Development - alpha project

« on: November 13, 2020, 02:02:17 am »

Hi Geert,
Thanks for the very quick reply.  This is exactly the feedback we were after.
The reason we went this direction is that it follows the Python style guide (https://www.python.org/dev/peps/pep-0008/#function-and-variable-names).  Although the code is small enough that it is not too late late to change.
When coming up with coding styles for our team to use we have found many contradictoy guidance and it is a balance to develop an in-house style.  e.g. Python's PEP8, Robert Martin's Clean Code, C# Coding Conventions.  You have now given us new guidance to think about.
p.s. we could have a facade that has the original calls, but this will contravene PEP8, but at least this isolates the issue.
Andy

7

Automation Interface, Add-Ins and Tools / Python Automation Interface - EA.Interop Development - alpha project

« on: November 12, 2020, 11:14:28 pm »

We are in the middle of the process of developing a Python module that exposes a portion of the EA Automation Interface.

We are publishing early alpha code (this can be found at: https://github.com/boro-alpha/ea_interop_service.git) to invite comments, so we can learn from the community. We will incorporate any good advice into later versions of the code.

This is an early version, so we would advise caution when using it.

We have developed this on the basis of the suggestion in https://sparxsystems.com/forums/smf/index.php?topic=3953.0.

We are hoping this will help people attempting to connect to the EA Automation Interface using Python - that they will now have access to more resources than we did.

We grew up using the C# dll: Interop.EA.dll and found the IntelliSense feature invaluable for quick code development.  When we started coding in Python, we found the the raw technique of connecting as a win32com client every time slowed things down. We built on the suggestion above by exposing the Automation Interface so that PyCharm’s code completion has something to work with (so similar to C#'s IntelliSense).  This has sped up our coding time - we hope others will find it as useful.

Any feedback would be welcome.

8

Automation Interface, Add-Ins and Tools / Replacing/renaming stereotypes

« on: November 10, 2008, 11:05:37 pm »

Hi all,

I'm having a problem attaching stereotypes neatly to elements and connectors throught the automation interface.  

Using the GUI, I have a stereotype <<test>> (base class <all>) and it is used in a class and a generalisation.  If I create a new stereotype <<test1>> (base class <all>), then change the class and generaliastion stereotypes to <<test1>>, then delete stereotype <<test>> I have neatly replaced <<test>> with <<test1>>.

If I do the same process using the automation interface I end up with three entries in the stereotype list:
  <<test1>> (base class <all>)
  <<test1>> (base class class)
  <<test1>> (base class generalisation)

Am I not refreshing or updating all of the appropriate tables? Or missing something else?

Thanks.

9

Automation Interface, Add-Ins and Tools / Re: Retrieving Connector End attributes

« on: November 05, 2008, 04:09:57 am »

Ok, there is a direct corrolation between the direction attribute and the navigability of the ends.  It looks like the conversion process only imported the direction and not the navigablity.  This is good enough for me to use.

10

Automation Interface, Add-Ins and Tools / Re: Retrieving Connector End attributes

« on: November 05, 2008, 01:13:01 am »

If it helps, I believe the model was created in another package (Rational XDE) and exported/imported to EA.  So the Connectors may have not been created or viewed using the GUI.

11

Automation Interface, Add-Ins and Tools / Retrieving Connector End attributes

« on: November 04, 2008, 11:01:14 pm »

Can someone tell me if this is a known issue or if I am doing something wrong when I use the Automation Interface.  I have a model that I'm reading and would like to process connectors depending on the navigablity of their ends.  When I ran my code over a model I received the following information about a connector (but I knew the client end was navigable):

10:32:20.906:Process Association (supplierID: 1459 clientID: 6552)
10:32:20.921:.... supplier navigable: False (“”)
10:32:20.921:.... client navigable: False (“”)

I opened the model in EA, examined the connector and ran the code again.  This time I got the result I was expecting:

11:24:09.234:Process Association (supplierID: 1459 clientID: 6552)
11:24:09.250:.... supplier navigable: False (“Unspecified”)
11:24:09.250:.... client navigable: True (“Navigable”)